MAP DISPLAY DEVICE AND NAVIGATION DEVICE 



BACKGROUND OF THE INVENTION 

Field of the Invention 
[0001] The present invention relates to map display devices 

and navigation devices and, more specifically, to a map display 
device and a navigation device for analyzing information externally 
provided through a communications part, and converting the 
information into applicable object models for display on a map. 

Description of the Background Art 
[0002] In a conventional type of map display device and 

navigation device, information about traffic and road regulations 
from any existing information communications system, and 
information from the Internet are not displayed on a navigation 
map but on a separately-provided schematic map. That is, such 
information is not converted into applicable object models for 
display on the navigation map. 

[0003] Here, the existing information communications system 

includes VICS (Vehicle Information and Communication System) , 
wherefrom road information about traffic A-e&\- jams and accidents 
is sent out in real time through FM multiplex broadcasting, radio 
beacon, optical beacon, and the like. 

[0004] The information about traffic -j-am. jams often includes 
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link numbers assigned to roads to specify which road is jammed. 
To represent such information, the conventional navigation device 
uses a schematic map additionally provided for the purpose. 
[0005] If represented on the navigation map, such information 

is not converted into object models applicable for display thereon, 
but a jammed road is accordingly changed merely in color. This 
is because ob j ect models prepared for map display are unchangeable, 
and thus color change is the only way left for the conventional 
navigation device to display such information without newly 
creating object models. 

[0006] In-tte a recent type of navigation device, an Internet 

browser is additionally installed, and information therefrom is 
displayed on a separately-provided map. Accordingly, with e-rr a 
communications part internally provided in the device, 
usually-isolated drivers in vehicles can fee-ee^^e communicate with 
the outside through the Internet. 

[0007] With reference to FIGS. 66 and 67, described next is 

the structure and operation of such conventional map display device 
and navigation device. FIG. 66 is a block diagram showing the 
structure of the conventional map display device, which includes 
an input part 2, a map data storage part 3, a map data generation 
part 400, a display 5, and a communications part 7. 
[0008] The input part 2 is provided for functional selection 

and point settings in this map display device. Outputted from 
the input part 2 is instruction information, which is forwarded 



to the map data generation part 400. 

[0009] The map data storage part 3 ^r^"-a<4^a^<^e stores 2D or 3D 

map data in advance indicating a specific area by geographical 
features, and in the area, intersections and road connections are 
5 defined by coordinates , shape, attribute, regulation information, 
and the like. The map data stored in the map data storage part 
3 is read as appropriate by the map data generation part 400 for 
usage . 

[0010] The communications part 7 transmit s /receives 

10 information to/from an external communications system through 
telephone lines, DAB (Digital Audio Broadcast) , and ground wave 
digital broadcasting, for example. From the communications part 
7, information is forwarded to the display 5 without any change. 
[0011] The map data generation part 400 generates a map image 

15 based on the map data stored in the map data storage part 3. Thus 
generated map image is displayed on the display 5 . Here, displayed 
on the display 5 is not only the map image., but also information 
derived through the Internet , VICS, and the like. Typically, such 
information is not displayed together with the map image,- but 
20 separately. 

[0012] FIG. 67 is a block diagram showing the structure of the 

conventional navigation device, which includes the input part 2, 
a position detection part 9, the map data storage part 3, a route 
selection part 100, a guiding part 110, the communications part 
25 7, and the display 5. Here, the navigation device is presumably 
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a vehicle-mounted type. 

[0013] The input part 2 is user-operable, and used for 

functional selection (e.g., processing item change, map switching, 
hierarchical level change) and point settings, for example. 
Outputted from the input part 2 is instruction information, which 
is forwarded to the route selection part 100. The position 
detection part 9 detects where the vehicle is currently posit ioned . 
Thus detected information about the vehicle's current position 
is provided to both the route selection part 100 and the guiding 
part 110. 

[0014] The map data storage part 3 4rfr-ad^arB^e stores 2D or 3D 

map data in advance indicating a specific area by geographical 
features, and in the area, intersections and road connections are 
defined by coordinates , shape, attribute, regulation information, 
and the like. The map data stored in the map data storage 3 is 
read as appropriate by the route selection part 100 and the guiding 
part 110 for usage. 

[0015] The communications part 7 transmits/receives various 

types of information to/ from an external system such as the Internet 
through telephone lines , DAB, and ground wave digital broadcasting, 
for example. From the communications part 7, information is 
forwarded to the display 5 without any change. 

[0016] The route selection part 100 reads the map data from 

the map data storage part 3 only for a required area according 
to the instruction information provided by the input part 2 . The 



route selection part 100 then determines a starting point and a 
destination based particularly on point information included in 
the instruction information, and information about the vehicle's 
current position provided by the position detection part 9. 
Thereafter, the route selection part 100 searches for a route 
minimum in cost between the starting point and the destination. 
A result obtained thereby is outputted to the guiding part 110 
as route information. 

[0017] Based on all of the route information from the route 
selection part 100, the information about the vehicle's current 
position from the position detection part 9, and the map data from 
the map data storage part 3, the guiding part 110 generates a 2D 
or 3D landscape map image for output to the display 5. 

[0018] The display 5 displays thus generated map image,- not 

together,- but separately from information derived through the 
Internet, VICS, and the like. 

[0019] As such, with the above-structured map display device 

and navigation device, the latest information about traffic 
^™^i>^R^a^ri^rr and a parking lot, for example, is easily accessible. 
Accordingly, with such information being the latest, the 
conventional map display device and navigation device 
advantageously have a user correctly understand what is going on 
on the way to his/her destination. 

[0020] The issue here is-™ that the conventional navigation 

device basically displays information displayed on the Internet 



browser separately from a navigation map image. As for VICS, 
traffic jam information therefrom is not represented on the 
navigation map image, but on a separately-provided schematic map 
image. As a result, the user becomes busy moving his/her eyes 
between two images for information comparison and relevance finding, 
which p^^^^^e^tv preferably requires the user to stop his/her 
vehicle. Therefore, when the vehicle is in motion, such advantages 
as described above are not fully used. This is always true even 
if the navigation device is a take-it-with-you type or a type 
equipped in some other mobile unit, for example. 
[0021] For the conventional navigation device, however, 

displaying various types of information all together on a 
navigation map image without newly creating object models is quite 
difficult, except changing the color of roads and other object 
models . 

[0022] Considered here is such a structure that any image and 

3D polygon data necessary for creating new object models are 
provided via a communications part. The map display device and 
the navigation device then appropriately arrange those on a map 
image for display. With such structure, however, the amount of 
information is consequently increased, and thus this structure 
is not economically practical. 

[0023] In another possible structure, the map display device 

and the navigation device previously store data necessary for 
object models varied in type y each corresponding to information. 



With such structure, however, a storage medium for object ?^e^e4r 
models is required to be large in capacity, resulting in low 
cost-effectiveness . 



SUMMARY OF THE INVENTION 

[0024] Therefore, an object of the present invention is to 

provide a map display device and a navigation device helping a 
user intuitively understand information without busily moving 
his/her eyes. Here, the information includes time varying 
information about regulations, traffic ^^-em jams, and various 
information accessible through the Internet, which are all arranged 
on a map image for display. 

[0025] Another object of the present invention is, in the map 

display device and the navigation device, to reduce the capacity 
of a storage medium for object me^k^l-- mode-Is while reducing the 
amount of incoming information. 

[0026] The present invention has the following features to 

attain the objects above. 

[0027] A first aspect of the present invention is directed to 

a map display device for converting externally provided 
communications information into an applicable object model for 
arrangement on a map image, the device comprising: 

an input part for receiving a user's instruction; 

a map data storage part for previously storing map data; 

an object model display information storage part for 
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storing ob j ect model display information for displaying the ob j ect 
model on said map image; 

a communications part for receiving the communications 
information ; 

a map data arranging part for creating the object model 
by interpreting the communications information and the ob j ect model 
display information provided by the object model display 
information storage part, and arranging the object model on the 
map; and 

a display part for displaying a resultant map image 
obtained by the map data arranging part. 

[0028] As described above, according to the first aspect, object 

models are appropriately arranged on a map space for display based 
on map data stored in the map data storage part, c orrariu n i c a t ions 
information provided by the communications part, and object model 
d i s p I a ya-Re-fe-k-e^ information stored in the object model display 
information storage part . Therefore, the user has no need to busily 
move s^Hrfre- his/her eyes to understand various time-varying 
information about regulations and traffic -^etm jams, for example, 
and information provided via the Internet. Further, since such 
information is represented in a manner aiming for the user' s 
intuitive understanding, better viewability is offered to the user . 
[0029] Here, stored in a recording medium in advance is object 

model display information, which requires real time change in 
display conditions and e^v^-emve- content. Therefore, if 



conditions are satisfied at time of execution, object model 
creation and deletion can be immediately done. Accordingly, the 
recording medium can be reduced in capacity, and further, even 
if the object model display information is updated or object model 
addition/ deletion is done via the communications part, the capacity 
is also reduced. Thus, the map display device can be economically 
practical . 

[0030] Also in the first aspect of the present invention, the 
communications information may include time-varying information, 
and if so, such time-varying information may be plurally included. 
Also, the communications information may include traffic 
information, advertisement information, andposition information 
corresponding to a specific position on the map image. 
[0031] By externally receiving such time-varying 

communications information, which is different from landmark 
information usually unchangeably included in the general type of 
map data, and by converting such information into applicable ob j ect 
models in real time, the user can easily and intuitively understand 
the latest information about traffic, availability level of parking 
lots, and the like. 

[0032] Also in the first aspect of the present invention, the 

object model display information may include information about 
the shape of the object model, and information about behavior in 
time and space of the object model. 

[0033] If this is the case, information to be stored in the 



object model display information storage part includes both 
information about shape andbehavior in time and space . Therefore, 
the information can be easily controlled,, especially when the 
object model display information is entirely or partially replaced 
with a new version. 

[0034] The information about behavior in time and space for 

the ob j ect model may be described in an object-oriented interpreter 
language nor needing fe^rfieg— Re — f^ee^ — £~e^ compilation. 
[0035] If so, information stored in the object model display 

information can be described in a script which can be immediately 
executed and easily created, making the object model display 
information independent of the map display device. Accordingly, 
the operation on the side of a server from which the object model 
display information is provided can be less loaded . Also, by using 
a standard script language such as JAVA, for example, the object 
model display information becomes widely accessible through a 
network, improving the object model display information in 
availability and reusability. 

[0036] Here, the information about behavior in time and space 

may include an execution condition and an execution function. 
[0037] If so, there is no need to fixedly set execution 

conditions. Accordingly, object models are not limited in their 
response to the user' s input and information provided by the 
communications part, rendering the object models appear in an 
unexpected and flexible manner. 
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[0038] Also in the first aspect of the present invention, the 

map data arranging part may arrange a newly created object model 
appropriately on a road image in the map image, or the object model 
f&&*f maybe plurally created for arrangement along the road image. 
By doing so, the user can easily and intuitively understand 
information relevant to the road, for example, information about 
an accident and traffic jam. 

[0039] Also, the map data arranging part may include an object 
model display information execution part for interpreting and 
executing the communications information and the corresponding 
object model display information provided by the object model 
display information storage part, an object creation part for 
creating an object model responsively to a result obtained by the 
object model display information execution part, and a data 
arranging part for arranging the object model on the map image. 
Further, possibly included therein are a 3D map image generation 
part for generating a 3D map image based on 2D map data provided 
by the map data storage part, and a 2D/3D coordinate transformation 
part for transforming a 2D object model created by the object model 
creation part into a 3D object model. 

[0040] With such structure, generated based on the 2D data are 

a 3D ob j ect model and a map image . Therefore , the recording medium 
for storing the object model display information and map data can 
be reduced in capacity. 

[0041] Next, in a second aspect of the present invention, the 



map display device further comprises a time information storage 
part for storing time information corresponding to a position of 
a mobile unit which moves according to schedule on a predetermined 
route, and the map data arranging part refers to the time information 
to create the object model corresponding to the mobile unit for 
arrangement on the map image. Also, the map data arranging part 
refers to the time information to select only the object model 
corresponding to the mobile unit to be displayed on the map image, 
and calculates a position of the object model on the map image 
for data arrangement. 

[0042] With such structure, the user will see a map image 

displaying an object model corresponding to the time information, 
for example, a train object on the move. Since such information 
is represented in a manner aiming for the user' s intuitive 
understanding, better viewability is offered to the user. For 
example, the user in an actual train can under stand more intuitively, 
together with the map image, where his/her train is currently 
located and in -^e- which direction it is heading. 

[0043] Next, in a third aspect of the present invention, the 

communications part receives the communication information 
including information for specifying a faregate (toll plaza) to 
be passed through, and if necessary, transmits charge information 
for e- charge processing, and the map data arranging part creates, 
if necessary, the object model corresponding to the communications 
information for arrangement on the map image, and generates the 



charge information. Also, the map data arranging part generates 
the charge information by referring to the communications 
information related to the faregate placed at an entrance and an 
exit for a predetermined chargeable section, and creates an object 
5 model including a fare for the chargeable section for arrangement 
on the map image. Also, the map display device may further 
ee^^-^^e-e-e' comprise a ticket information storage part for storing 
ticket information corresponding to a ticket used for paying the 
fare for the chargeable section. Here, the ticket information 

10 may include information about an expiration date of the ticket, 
and the map data arranging part may refer to such information to 
create a message, if necessary, for display on the display part. 
[0044] With such structure, the map display device operates 

as a terminal of an automated fare-collection system so that better 

15 usability is offered to the user, and further, represents various 
information such as a fare in a more intuitive manner so that better 
viewability is also offered to the user. 

[0045] In a fourth aspect of the present invention, the 

communications part receives the communications information 

20 including position information about any available vehicle, and 
when the user desires to take one of the available vehicles, 
transmits selected vehicle information including information for 
specifying which vehicle the user desires to take, and the map 
data arranging part creates the object model corresponding to the 

25 communications information for arrangement on the map image, and 
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when the user desires to take one of the available vehicles, 
generates the selected vehicle information. Here, the available 
vehicles may be located within a predetermined area range close 
to a current position, and may move according to schedule on a 
predetermined route. Also, the communications part may transmit 
a request for vehicle information including the current position 
for an externally provided information center, and receives the 
communications information including the position information of 
the available vehicles selected by the information center. 
Further, the map data arranging part may refer to the communications 
information, create an ^rh-e object model -earek corresponding to -fe-ke- 
each: available vehicle, and if necessary, create an object model 
each including information about each of the available vehicles 
for arrangement on the map image. 

[0046] With such structure, the map display device operates 

as an information terminal about any available vehicle, for example, 
taxis and buses, and offers better usability to the user. Further, 
various information are represented in a more intuitive manner 
about where the taxis and buses are currently located and fares 
therefor so that better viewability is also offered to the user. 
[0047] In a fifth aspect of the present invention, a navigation 

device for converting externally provided communications 
information into an applicable object model for arrangement on 
a map image, and *£a4en^ — a providing guidance to a destination 
comprises, in addition to the map display devices of the first 



to third aspects, a position detection part for detecting a current 
position; a route selection part for selecting a route to the 
destination based on the instruction provided by the input part, 
the current position detected by the position detection part, and 
the map data stored in the map data storage part; and a guiding 
part for providing i^aMfrg™4^e™guidance to the destination in 
response to the communications information received by the 
communications part, the route selected by the route selection 
part, the current position detected by the position detection part , 
and the map data provided by the map data storage part, and eufew-fe 
cutputting a resultant map image obtained by the map data arranging 
part . 

[0048] As described above, in the fifth aspect of the present 

invention, realized is a navigation device similarly effective 
to the map display device of the above described first to fourth 
aspects . 

[0049] A sixth aspect of the present invention is such a map 

display method as to functionally realize the map display device 
of the first to fourth aspects. With such map display method, 
externally provided communications information is arranged on the 
map image in the form of applicable object models. 
[0050] A seventh aspect of the present invention is such 

navigation method as to functionally realize the navigation device 
of the fifth aspect. With such navigation method, externally 
provided communications information is arranged on the map image 



in the form of applicable object models. 

[0051] An eighth aspect of the present invention is a program 

which realizes the map display method in the sixth aspect, and 
a computer-readable recording medium on which the program is 
stored. 

[0052] A ninth aspect of the present invention is a program 
which realizes the navigation method in the seventh aspect, and 
a computer-readable recording medium on which the program is 
stored. 

[0053] These and other objects, features, aspects and 

advantages of the present invention will become more apparent from 
the following detailed description of the present invention when 
taken in conjunction with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0054] FIG. 1 is a block diagram showing the structure of a 

map display device according to a first embodiment of the present 
invention ; 

FIG . 2 is a diagram showing the structure of a map display 
device, which is realized in a general computer system; 

FIG. 3 is a flowchart showing the operation of a map 
data arranging part 4 in the map display device of FIG. 1; 

FIG. 4 is a diagram showing, in a tree structure, the 
contents of information transmitted from a communications part 
7; 



FIG. 5 is a flowchart showing the detailed process of 
subroutine step S13 in FIG. 3; 

FIG. 6 is a diagram exemplarily demonstrating the 
contents of object model display information; 

FIG. 7 is a diagram showing a specific example of object 
model display information corresponding to miscellaneous 
information as shown in FIG. 4; 

FIG. 8 is a diagram in assistance of demonstrating when 
to carry out methods in information about behavior in time and 
space in FIG. 7 , 

FIG. 9 exemplarily shows function names and contents 
thereof, corresponding to traffic information, stored in object 
model display information storage part 6; 

FIG. 10 exemplarily shows function names and contents, 
corresponding to emergency information, parking lot information, 
and vehicle-to-vehicle communications information, stored in the 
object model display information storage part 6; 

FIG. 11 is a diagram exemplarily showing what the traffic 
jam information provided from VICS, for example, via the 
communications part 7 carries in what order; 

FIG. 12 is a flowchart showing the procedure when a 
function to present traffic jam information is executed; 

FIG. 13 shows an interrelation table indicating the 
relation to map data stored in the map data arranging part 4; 

FIG. 14 shows a schematic map viewed from above for 
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showing a relation between vehicle polygons and roads; 

FIG. 15 shows the same map as FIG. 14 but viewed from 
an interpolation point number 544 at ground level; 

FIG. 16 shows an exemplary map image generated by the 
map display device of the first embodiment; 

FIG. 17 is ablock diagram showing the detailed structure 
of the map data arranging part 4; 

FIG. 18 is ablock diagram showing the detailed structure 
of an execution part 41; 

FIG. 19 is a flowchart showing the detailed process of 
subroutine step S133; 

FIG. 20 is ablock diagram showing the detailed structure 
of a display data arranging part 42 , a resultant map image generated 
thereby is of 2D landscape; 

FIG. 21 is ablock diagram showing the detailed structure 
of the display data arranging part 42, a resultant map image 
generated thereby is of a bird' s eye view; 

FIG. 22 is a diagram demonstrating a technique for 
creating a bird' s eye view by subjecting 2D map data to perspective 
transformation ; 

FIG. 23 shows an exemplary map image of a bird's eye 
view generated by the display data arranging part 42; 

FIG. 24 is ablock diagram showing the detailed structure 
of the display data arranging part 42, a resultant image data 
generated thereby is of a 3D landscape different from a bird' s 
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eye view; 

FIG. 2 5 is ablock diagram showing the detailed structure 
of a 3D map data generation part 147; 

FIG. 2 6 is ablock diagram showing the detailed structure 
5 of the display data arranging part 42, which receives 2D data from 
the execution part 41 and 3D map data from the map data storage 
part 3, and generates a map image of 3D landscape; 

FIG. 27 is a diagram exemplarily showing several image 
files prepared as 2D shape information in object model display 
10 information; 

FIG. 28 shows an exemplary map image of 3D landscape 
generated by the display data arranging part 42 of FIG. 26: 

FIG. 2 9 is an exemplary map image of 3D landscape on 
which 2D object models indicative of a traffic jam are arranged; 
15 FIG. 30 is another exemplary map image of 3D landscape 

on which 2D objects indicative of an accident are arranged; 

FIG. 31 is still another exemplary map image of 3D 
landscape on which 2D objects indicative of construction are 
arranged; 

20 FIG. 32 shows the same map image as FIG. 31, but the 

viewpoint is different; 

FIG. 33 is a block diagram showing the structure of a 
navigation device according to a second embodiment of the present 
invention ; 

25 FIG. 34 is a diagram showing the structure of a navigation 
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device, which is realized in a general computer system; 

FIG. 35 is a flowchart showing a basic flow of processing 
in the navigation device of the second embodiment; 

FIG. 36 is a block diagram showing the structure of a 
5 map display device according to a third embodiment of the present 
invention ; 

FIG. 37 shows exemplary time information stored in a 
time information storage part 8; 

FIG. 38 is a flowchart showing the operation of the map 
10 data arranging part 4 in the map display device of the third 
embodiment ; 

FIG. 39 is a flowchart showing the detailed process of 
subroutine step S42 in FIG. 38; 

FIG. 40 is a diagram showing which train reaches at what 
15 station at what time; 

FIG. 41 is a block diagram showing the structure of a 
map display device of a map display device according to a fourth 
embodiment of the present embodiment; 

FIG. 42 is a flowchart showing the processing carried 
20 out by the map data arranging part 4, which operates as a terminal 
of an automated fare-collection system; 

FIG. 43 is a diagram showing predetermined symbols to 
be displayed in step S615; 

FIG. 44 is a flowchart showing the detailed process of 
25 subroutine step S616 in FIG. 42; 
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FIG. 45 is a diagram showing exemplary ticket information 
stored in the ticket information storage part 12; 

FIG. 46 is a diagram showing information transmitted 
by the automated fare-collection center in a case where a user 
5 uses a train with the map display device carried along; 

FIG. 47 is a block diagram showing the structure of a 
navigation device of a fifth embodiment of the present invention: 

FIG. 48 is a flowchart showing the processing in the 
navigation device, operating as a terminal in an automated 
10 toll-collection system; 

FIG. 49 is a diagram showing predetermined symbols to 
be displayed in step S627 in FIG. 48; 

FIG. 50 is a diagram showing information transmitted 
by the automated toll-collection center in a case where the present 
15 navigation device is used as an ETC terminal; 

FIG. 51 is a diagram showing the entire structure of 
a taxi call system including a navigation device operating as a 
taxi call terminal; 

FIG. 52 is a flowchart showing the operation of a central 
20 processing part 40 in a taxi center 2000 for dispatching a taxi; 

FIG. 53 is a flowchart showing the processing executed 
by a navigation device of a sixth embodiment of the present 
invention ; 

FIG. 54 is a flowchart showing the detailed process in 
25 subroutine step S87; 
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FIG. 55 is a diagram showing a specific example of taxi 
object model display information; 

FIG. 56 is a diagram exemplarily showing a function name 
and contents thereof for a taxi call; 
5 FIG. 57 is a diagram showing the operation of the 

navigation device of the sixth embodiment; 

FIG. 58 is a diagram showing the entire structure of 
a bus riding system including a navigation device 1050 operating 
as a terminal for notifying buses of a user' s intention of riding; 
10 FIG. 59 is a flowchart showing the operation of a central 

processing part 45 in a bus center 4000; 

FIG. 60 is a flowchart showing the processing executed 
by a navigation device operating as a terminal for examining bus 
information ; 

15 FIG. 61 is a flowchart showing the detailed process in 

subroutine step S970; 

FIG. 62 is a diagram showing a specific example of bus 
object model display information; 

FIG. 63 is a diagram exemplarily showing a function name 
20 and contents thereof for a bus call; 

FIG. 64 is a diagram showing the operation of a navigation 
device of a seventh embodiment; 

FIG. 65 shows an exemplary map image having other users' 
positions each displayed on the map image; 
25 FIG. 66 is a block diagram showing the structure of a 
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conventional map display device; and 

FIG. 67 is a block diagram showing the structure of a 
conventional navigation device. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 
[0055] 4-Basic Concept of the Inventions- 
Prior to describing the present invention in detail with 
embodiments, a basic concept thereof is described for easy 
understanding . 

[0056] Devices according to embodiments of the present 

invention each receive external information, convert the 
information into applicable object models equal in dimension to 
a map space (e.g., 3D map space) displayed thereon, and arrange 
the resultant object models in the map space for display. 
Accordingly, a user can intuitively understand time-varying 
information about regulations and traffic jams, and various 

information available from the Internet without busily moving 
his/her eyes. The devices of the following embodiments thus can 
offer better viewability and usability to the user. 
[0057] A -±-#~B€^^-e- 3D, -*^e map ^ri-^e-l-y looks rather realistic, 

but the amount of information is increased if polygon data 
corresponding to 3D ob j ect models is transmitted as it is . Further, 
in such a case, data arrangement is not carried out on a terminal 
side, and thus data is not customized to suit the circumstances 
for display. Conversely, with devices of the present invention, 



data is transmitted after being compressed, and a user interface 
can be flexibly built to suit the circumstances and the user' s 
preferences . 

[0058] Note herein that-- the present devices are each described 
as a vehicle-mounted type or a take-it-with-you type. This is 
not restrictive, and if described as the vehicle-mounted type, 
the device also may be the take-it-with-you type or a type equipped 
in some other mobile unit, for example. 

[0059] Here, the foregoing description of the basic concept 

shall be applicable only for easy understanding of the present 
invention, and shall not be applied for unreasonably narrow 
interpretation of the scope of the invention. 
[0060] -fFirst Embodiment^ 

FIG. 1 is a block diagram showing the structure of a 
map display device according to a first embodiment of the present 
invention. In FIG. 1, the map display device includes the input 
part 2, the map data storage part 3, a map data arranging part 
4, the display 5, an object model display information storage part 
6, and the communications part 7. Here, any constituent found 
in FIGS. 66 and 67 is denoted by the same reference numeral. 
[0061] The input part 2 is user-operable and composed of a remote 

controller, touch sensor, keyboard, mouse, and the like. With 
the input part 2, functional selection and point settings for the 
map display device (processing item change, map switching, 
hierarchical level change) , for example, are done . Outputted f rom 



the input part 2 is instruction information, which is forwarded 
to the map data arranging part 4 . 

[0062] The map data storage part 3 is composed of an optical 

disk (e.g., CD, DVD), hard disk, semiconductor memory card (e.g., 
5 SD card), and the like. Stored in the map data storage part 3 
is 2D or 3D map data indicating a specific area by geographical 
features, and in the area, intersections and road connections are 
defined by coordinates , shape, attribute, regulation information, 
and the like. The map data stored in the map data storage 3 is 

10 read as appropriate by the map data arranging part 4 for usage. 
[0063] The communications part 7 transmit s /receives 

information to/from an external system typically through the 
Internet, and generally through telephone lines, DAB, and ground 
wave digital broadcasting, for example. 

15 [0064] As is the map data storage part 3 , the obj ect model display 

information storage part 6 is also composed of an optical disk 
(e.g., CD, DVD), hard disk, semiconductor memory card (e.g., SD 
card), and the like. Stored therein is information about a 
technique for presenting 2D or 3D object models on a map image 

20 according to the information provided by the communications part 
7 or the input part 2. Ai>^rt™~4^ The technique and the details 
of the information are left for later description. 
[0065] The map data arranging part 4 arranges object models 

in a map space. This arrangement is done based all on the map 

25 data stored in the map data storage part 3, the information provided 
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by the communications part 7, and the information stored m the 
object model display information storage part 6. Here, the map 
data arranging part 4 may be functionally realized in the form 
of software controlled by a CPU. If so, a storage medium 
accordingly storing a program for controlling the software is 
implemented in the map display device. The program may be ■^fee 
■a**e- transmitted over a communications circuit. 

[0066] The display 5 is composed of a display device (e.g., 

liquid crystal display, CRT display) , speaker, and the like, and 
displays a resultant map image provided by the map data arranging 
part 4 . Alternatively, the display 5 may output sounds for guidance 
with or without performing display. 

[0067] Such structured map display device of FIG. 1 can be 

realized in a general computer system. The structure of a map 
display device realized as such is shown in FIG. 2. 
[0068] In FIG. 2, the map display device includes a CPU 332, 

ROM 333, RAM 334, an output part 335, an input part 336, and a 
communications part 338, all of which are interconnected by a system 
bus. Here, presumably, the ROM 333 possibly includes a storage 
device such as a. read-only memory provided inside the computer 
and an external storage medium (e.g., optical disk (CD, DVD, for 
example) , semiconductor memory card) . Similarly, the RAM 334 is 
presumed to possibly include a storage device such as a 
readable/writable memory provided inside the computer and a 
readable/writable external storage medium (e.g., optical disk 



(CD-R/W, DVD-RAM, for example) , hard disk, semiconductor memory 
card) . 

[0069] In FIG. 2, the CPU 332 operates in accordance with a 

program stored in either or both of the ROM 333 and the RAM 334. 
5 The map data arranging part 4 is functionally realizedby the program. 
In such case, a recording medium typically storing such program 
is implemented in the map display device. The program may be 4~£te 
■e*je— transmitted over a communications circuit. 

[0070] The ROM 333 typically includes the map data storage part 

10 of FIG. 1, or the RAM 334 may do so entirely or partially . Similarly, 
the RAM 334 typically includes the ob j ect model display information 
storage part 6, or the ROM 333 may do so. 

[0071] As such, differences are rather apparent between the 

map display device of FIG . 1 and the conventional map display device 

15 of FIG. 66. Indetail, the obj ect model display information storage 
part 6 is newly provided, and the map data arranging part 4 is 
provided as an alternative to the map data generation part 400, 
which receives an output from the communications part 7 . Described 
next is the operation of"^ef3-e these parts. 

20 [0072] FIG. 3 is a flowchart showing the operation of the map 

data arranging part 4 in the map display device of FIG. 1. With 
reference to FIG. 3, the operation of the map data arranging part 
4 is described. 

[0073] In step Sll of FIG. 3, the map data arranging part 4 

25 first reads, from the map data storage part 3 , map data corresponding 
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to a map number, a display command, and the like, provided by the 
input part 2 . 

[0074] Next, in step S12, the map data arranging part 4 reads 

time-varying communications information from the communications 
part 7 . As 4rB- time-varying, the communications information needs 
to be read at least once from an external information source via 
the communications part 7. In this sense, the communications 
information is unlike general landmark information which is only 
about the location and shape of landmark buildings. 
[0075] The information provided from the communications part 

7 includes such information as shown in FIG. 4, for example. FIG. 
4 is a diagram showing, in a tree structure, the information 
transmitted from the communications part 7. As shown in FIG. 4, 
the information is mainly classified into traffic information, 
emergency information, parking lot information, 

vehicle-to-vehicle communications information, andmiscellaneous 
information. Here, the information in FIG . 4 is merely an example , 
and may not necessarily include all of those information or may 
include other information. 

[0076] In FIG. 4, the traffic information includes traffic jam 

information, accident information, under -con struct ion 
information, and freezing information . Specifically, the traffic 
jam information is composed of a traffic jam information ID and 
link data. Here, a link is a unit for positionally specifying 
a specific part of a road. The link data typically includes link 
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information, From information, To information, and lane 
information. Here, the traffic jam information ID is an 
information identification number for identifying that the 
accompanying link data is the traffic jam information. The link 
information is a link number corresponding to each road to specify 
which road is j ammed . The From information indicates , exemplarily 
by interpolation point number, a starting point of the traffic 
jam on the link, while the To information indicates an ending point. 
The lane information indicates, exemplar ily by lane number, which 
lane is jammed. Here, the link data included in the traffic jam 
information may be plural. 

[0077] The accident information is composed of an accident 

information ID and link data. The link data typically includes 
link information, latitude/longitude, and lane information . Here, 
the accident information ID is an information identification number 
for identifying that the accompanying link data is the accident 
information. The link information is a link number corresponding 
to each road to specify on which road the accident occurred. The 
latitude/longitude shows the applicable link by latitude and 
longitude. The lane information indicates, exemplarily by lane 
number, on which lane the accident occurred. 

[0078] The under-construct ion information is composed of an 

under-cons truction information ID and link data. The link data 
typically includes link information, From information, To 
information, and lane information. Here, the under-construct ion 



information ID is an information identification number for 
identifying that the accompanying link data is the 
under-construction information. The link information is a link 
number corresponding to each road to specify which road is under 
construction. The From information indicates, exemplarily by 
interpolation point number, a starting point of the construction 
on the link, while the To information irulicates an ending point. 
The lane information indicates, exemplar ily by lane number, which 
lane is under construction. Here, the link data included in the 
under-construction information may be plural. 

[0079] The freezing information is composed of a freezing 

information ID and link data. The link data typically includes 
link information, From information, and To information. Here, 
the freezing information ID is an information identification number 
for identifying that the accompanying link data is the freezing 
information. The link information is a link number corresponding 
to each road to specify which road is frozen . The From information 
indicates, exemplarily by interpolation point number, a starting 
point of freezing on the link, while the To information indicates 
an ending point. The lane information indicates, exemplarily by 
lane number, which lane is frozen. Here, the link data included 
in the freezing information may be plural. 

[0080] Next, the emergency information includes ambulance 

information, police car information, and fire engine information. 
Specifically, the ambulance information is composed of a medical 
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emergency information ID and link data. The link data typically 
includes current position information, To information, and route 
information. Here, the medical emergency information ID is an 
information identification number for identifying that the 
accompanying link data is the ambulance information. The current 
position information indicates where the ambulance currently is. 
The To information indicates a destination of the ambulance, and 
may be a location where an injured or sick person is waiting, a 
location or a facility number of a hospital, and the like. The 
route information is -afe^*24r~an estimated route through which the 
ambulance is expected to pass. Here, the route information may 
be calculated by a route search carried out based on the current 
position information and To information. 

[0081] The police car information is composed of a police car 

information ID and link data. The link data typically includes 
current position information, To information, and route 
information. The police car information ID is an information 
identification number for identifying that the accompanying link 
data is the police car information. The current position 
information indicates where the police car currently is. The To 
information indicates a destination of the police car, and may 
be a location where an incident occurred, a location or a facility 
number of a police station, and the like. The route information 
is about an estimated route through which the police car is expected 
to pass . Here, the route information may be calculated by a route 



search carried out based on the current position information and 
To information. 

[0082] The fire engine information is composed of a fire 

fighting information ID and link data. The link data typically 
includes current position information, To information, and route 
information. The fire fighting information ID is an information 
identification number for identifying that the accompanying link 
data is the fire engine information. The current position 
information indicates where the fire engine currently is. The 
To information indicates a destination of the fire engine, and 
may be a location where a fire broke out, a location or a facility 
number of a hospital, and the like. The route information is about 
an estimated route through which the fire engine is expected to 
pass. Here, the route information may be calculated by a route 
search carried out based on the current position information and 
To information. 

[0083] The parking lot information includes parking lot 

availability information, and the like. The parking lot 
availability information is composed of a parking lot information 
ID and link data, for example. The link data typically includes 
location information, a parking lot ID, and availability 
information. The parking lot information ID is an information 
identification number for identifying that the accompanying link 
data is the parking lot information. The location information 
indicates where the parking lot is located. The parking lot ID 



is a facility number assigned to the parking lot . The availability 
information indicates the availability level of the parking lot. 
[0084] The vehicle-to-vehicle communications information 

includes inter-vehicle distance information, and the like. The 
inter- vehicle distance information is composed of an inter- vehicle 
distance information ID and link data, for example. The link data 
typically includes information about an inter-vehicle distance 
to a vehicle ahead, a vehicle type thereof, an inter-vehicle 
distance to a vehicle behind, and a vehicle type thereof. The 
inter-vehicle distance information ID is an information 
identification number for identifying that the accompanying link 
data is the inter-vehicle information. 

[0085] Lastly, the miscellaneous information includes 

landmark information, sports information, and gambling 
information. Specifically, the landmark information is composed 
of a facility ID and link data, for example. The landmark 
information herein includes offer information about landmark 
buildings, specifically about a shop type, advertisement, and the 
like . To be specific, the advertisement information includes text 
or image information for advertising the shop and merchandise, 
for example, what services are available, when4~s-a sale is occurring, 
and what type of event is expected. The link data typically 
includes adjacent link information, latitude/longitude, and the 
offer information as above described. The facility ID is an 
information identification number for identifying that the 



accompanying link data is information about a landmark building, 
for example . The adj a cent link information is about a link closest 
to the landmark building. The latitude/longitude indicates the 
location of the landmark building by latitude and longitude. 
5 [0086] The sports information is composed of a facility ID and 

link data, for example . The link data typically includes adj acent 
link information, latitude/longitude, and of fer information . The 
facility ID is an information identification number for identifying 
that the accompanying link data is information about a sports 
10 facility, for example. The adjacent link information is about 
a link closest to the sports facility. The latitude/longitude 
indicates the location of the sports facility by latitude and 
longitude. The offer information is about a game result, for 
example . 

15 [0087] The gambling information is composed of a facility ID 

and link data, for example. The link data typically includes 
adjacent link information, latitude/longitude, and offer 
information. The facility ID is an information identification 
number for identifying that the accompanying link data is 

20 information about a gambling facility, for example. The adjacent 
link information is about a link closest to the gambling facility. 
The latitude/longitude indicates the location of the gambling 
facility by latitude and longitude . The offer information is about 
a gambling result, for example. 

25 [0088] Next, in subroutine step S13 in FIG. 3, the map data 



arranging part 4 refers to both the communications information 
read by the communications part 7 and the information stored in 
the object model display information storage part 6 so as to create 
a 2D or 3D object model. Thus created object model is arranged 
on the map data read from the map data storage part 3. The details 
of subroutine step S13 are described in detail next with reference 
to FIG. 5. 

[0089] FIG. 5 is a flowchart showing the detailed process of 

the subroutine step S13 in FIG. 3. In step S131 in FIG. 5, the 
map data arranging part 4 determines whether there is any 
communications information read by the communications part 7, and 
if any, determines whether a map image covers corresponding 
coordinates included in the communications information. If there 
is no communications information, or if the map image does not 
cover such coordinates, this is the end of subroutine step S13, 
and the procedure returns to the main routine. Conversely, if 
there is any communications information, and if the map covers 
the corresponding coordinates, the procedure goes to step S132. 
[0090] In step S132, the map data arranging part 4 reads, from 

the object model display information storage part 6, object model 
display information corresponding to the communications 
information. Here, the object model display information may be 
entirely or partially included in the communications information. 
[0091] Here, when creating an object model, the map data 

arranging part 4 typically assigns parameters of the communications 



information read by the communications part 7 to a corresponding 
function in the object model display information. Thus created 
object model is so arranged on the map image as to positionally 
match in a map space. A resultant map image is displayed on the 
display 5 (subroutine step S133) . 

[0092] Described next is -cH&eHrt— the object model display 

information . FIG . 6 is a diagram exemplarily showing the contents 
of the object model display information, which is typically 
classified into information about shape and behavior in time and 
space . 

The information about shape is directly represented by 
a description specifying polygon information and a texture mapped 
thereto, or indirectly represented by a description specifying 
a function and parameters. 

[0093] The information about behavior in time and space is 

represented in suchmanner as a predetermined processing is carried 
out with a predetermined condition satisfied. With such 
representation, there is no need to fixedly set execution 
conditions. Accordingly, object models are not limited in their 
response to the user' s input and information provided by the 
communications part 7, rendering the object models able to appear 
in an unexpected and flexible manner. This is described in more 
detail below. Note that™ the information about behavior in time 
and space can also be represented in a format simply including 
a function name and contents thereof. 



[0094] The information about behavior in time and space of FIG. 

6 typically includes CREATE and CAR_NEAR. Specif ically, CREATE 
describes a method carried out at time of object model creation, 
while CAR_NEAR a method carried out when a vehicle comes close 
to a predetermined distance range. 

[0095] Here, with reference to FIG . 7, such obj ect model display 

information is described with a detailed specific example. 
[0096] In FIG. 7, obj ect model display information 70 0 includes 

information about shape 701 and information about behavior in time 
and space 702. The information about shape 701 may be 3D 
information stored in a file named >x gas_station . obj for example . 
Or, the information about shape 701 may include information for 
defining a polygon by width, height, and depth, and a file named 
"esso_station.bmp^ specifying a texture mapped to the polygon, 
for example. Here, the information about shape 701 includes 
position information. In FIG. 7, the position information is 3D 
coordinates at which an object model is displayed. Two graphics 
on the right upper side are examples drawn according to the 
information exemplified in FIG. 7. 

[0097] The information about behavior in time and space 702 

is not limited in description language, but is typically described 
in an object-oriented interpreter language (e.g., Sun 
Microsystems' Java Language) . Since there is no need for 
compilation, a script in such language can be immediately executed 
and easily created. Therefore, such script is suited-^fe^ for 
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this embodiment. 

[0098] In the information about behavior in time and space 702 

of FIG. 7, a Pos method creates an obj ect model at space coordinates 
corresponding to a facility ID. A Dir method represents a gradient 
of the object model in a 3D space. A Shape method draws the object 
model. A BlinkObj ect method makes a specific object model flash 
on and off when a distance r between the object model and a vehicle 
becomes a predetermined value or smaller. As such, the information 
about behavior in time and space 702 is so described as to make 
a specific object flash on and off when the vehicle comes close 
within the distance r. 

[0099] FIG. 8 is a diagram in assistance of demonstrating when 

to carry out the methods in the information about behavior in time 
and space 702. In FIG. 8, Road objects each denote a road on a 
map, and a box on the upper side denotes an object drawn on the 
map. Here, presumably, the vehicle runs along a Route shown in 
a bold line. When the vehicle is at position 1, the object model 
shows no change, but at position 2, the vehicle comes within the 
distance r and thus the object starts blinking on and off with 
the methods in the information about behavior in time and space 
702 carried out. 

[0100] Next, with reference to FIGS. 9 and 10, described is 

the case that the information 702 is represented in a format 
including a function name and contents thereof . FIG . 9 exemplarily 
shows function names and contents, corresponding to the 
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above-described traffic information, stored in the object model 
display information storage part 6. FIG. 10 exemplarily shows 
function names and contents, corresponding to the above-described 
emergency information, parking lot information, and 
vehicle-to-vehicle communications information, stored in the 
object model display information storage part 6. 
[0101] In FIG. 9, assuming that the traffic jam information 

comes from VICS, for example, via the communications part 7, and 
if a map image covers corresponding coordinates, the map data 
arranging part 4 executes a function to present traffic jam 
information in a manner described. In detail, a first step is 
reading road information (e.g., a table for defining roads by 
element) corresponding to the link information, From information, 
and To information read by the communications part 7 . A second 
step is calculating space coordinates for a section corresponding 
to the information read in the first step. Lastly, a third step 
is creating an object model such as vehicle polygon and "jammed 7 ' 
sign in an intermediate buffer for arrangement in the map space. 
After those steps, an object model in the shape of vehicle, for 
example, is created and arranged along the road. In this manner, 
the user can intuitively understand that the road is j ammed without 
busily moving his/her eyes. 

[0102] Here, such processing is similarly done to other 

communications information, and executed thereby is a 
corresponding function stored in the object model display 



information storage part 6. As for the functions, see FIGS. 9 
and 1 0 . 

[0103] Described next is the processing when the function to 

present traffic jam information is executed in more detail. By 
referring to FIG . 11, described fir st is the traffic j am information, 
which is read from the communications part 7 by the map data arranging 
part 4 . 

[0104] FIG. 11 is a diagram exemplarily showing what the traffic 

jam information provided from VICS, for example, via the 
communications part 7 carries in what order. The traffic jam 
information of FIG. 11 includes a traffic jam information ID 551, 
a traffic jam link number 552, a start interpolation point number 
553, an end interpolation point number 554 , and a j ammed lane number 
555, respectively corresponding to the traffic jam information 
ID, link information, From information, To information, and lane 
information in the traffic jam information of FIG. 4. 
[0105] The traffic jam information ID 551 is an information 

identification number for identifying that the accompanying link 
data is the traffic jam information. The traffic jam link number 
552 is a link number indicating which road is j ammed. For example, 
when the traffic jam link number 552 indicates 1010, it means that 
a road having a link number 1010 is jammed. Known with the start 
and end interpolation points numbers 553 and 554 is what specific 
part of the road is jammed. For example, if the start and end 
interpolation point numbers 553 and 554 show 1 and 2, respectively, 
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it means a section between interpolation points 1 and 2 is jammed 
on the road. The jammed lane number 555 shows, by lane number, 
which lane is jammed. Here, as stated above, the link data may 
be plurally included in the traffic jam information. 
[0106] Described next is the procedure when the function to 

present traffic j am information is executed . FIG. 12 is a flowchart 
showing such procedure . In step SI 0 1 in FIG . 12, once such function 
is executed, the map data arranging part 4 reads, from the map 
data storage part 3, information showing the relation between the 
traffic jam information and corresponding map data (hereinafter, 
such information is referred to as interrelation table) . 
[0107] FIG. 13 shows an exemplary interrelation table stored 

in the map data arranging part 4. Included in the table of FIG. 
13 are a link number, a start interpolation point number, an end 
interpolation point number, ^HSre a number of sequences, and one 
or more sets of a sequence number, a start reference point number, 
and an end reference point number. 

[0108] Here, a sequence is a minimum unit of the road found 

in the map data stored in the map data storage part 3, and the 
number of sequences indicates with how many sequences the road 
is structured by. The sequence is drawn by a linear line, broken 
line, curve, and the like, and a reference point is for controlling 
the sequence. The number of reference points provided to one 
sequence is two or more, and numbers assigned thereto are 
consecutive. Accordingly, with a set of sequence number and start 



and end reference point numbers, an arbitrary sequence in the map 
data can be uniquely indicated. 

[0109] Here, such set as described above varies depending on 

the data structure of map data. Also, the exemplified set is not 
restrictive, and any data will do as long as an arbitrary sequence 
in the map data is uniquely indicated. 

[0110] Next, in step S102 in FIG. 12, the map data arranging 
part 4 refers to the interrelation table to find the number of 
sequences in the map data. In the example of FIG. 13, the number 
of sequences is 3. 

[0111] In step S103, the map data arranging part 4 then compares 

thus found number of sequences with a number indicating how many 
sequences are so far processed. If those two numbers are equal, 
the map data arranging part 4 determines that the processing is 
now completed, and the procedure jumps to step S108. Otherwise, 
the procedure goes to step S104. 

[0112] In step S104, the map data arranging part 4 searches 

the map data storage part 3 for 3D coordinates corresponding to 
a predetermined set (the first set in initial value) among from 
those read in step S101. Here, the coordinates that are searched 
for may be 2D, and stored in a predetermined table provided in 
the map data storage part 3 or calculated from the map data. 
[0113] Next, in step -84-6-4- 3105, the map data arranging part 

4 carries out offset processing for adjusting the 3D coordinates 
read in step--844^4K- S101, Since a string of those coordinates 



corresponds to a center line of the road, ^e^e-^e-e-e^^ 
e^-e^#4^^r^- the string needs to be calculated in s tep SI 0 4 and adj us ted 
in step SI 0 6 to come to a middle line of a lane indicated by the 
jammed lane number 555. 

[0114] In step €~H^4 S106, the map data arranging part 4 also 

defines, by position, size, number, orientation, and the like, 
a 3D vehicle polygon specified by the currently executing function, 
as appropriate. 

[0115] After such processing for one specific road is completed, 
in step -84r0-& S107, the map data arranging part 4 increments the 
number of sequences so far processed, and then selects another 
set among from those read in step S103 . The procedure then returns 
to step S103. 

[0116] After every sequence is processed, in step S108, the 

map data arranging part 4 reads the data about vehicle polygon 
from the map data storage part 3 or the object model display 
information storage part 6. Next, the map data arranging part 
4 stores, in the intermediate buffer, the vehicle polygon 
appropriately defined in step S10 6 by position, size, number, 

orientation, and the like. Then, the vehicle polygon is arranged 
on the map data for display on the display 5. Here, the vehicle 
polygon is not restricted to be 3D, and the vehicle maybe represented 
in 2D or an actual image. 

[0117] FIG. 14 shows a schematic map viewed from above for 

showing a relation between vehicle polygons and roads. In FIG. 



14, a reference numeral 546 denotes a road having assigned a link 
number 1000 and including interpolation point numbers -44# 543 and 
-§4-3- 544. A reference numeral 547 denotes a road having assigned 
the link number 1010 and including interpolation point numbers 
444 541 and #44 542. As the interrelation table of FIG. 13 shows, 
the road 547 is structured by 3 sequences, corresponding to 
sequences 5471 to 5473 in FIG. 14. To be specific, as for the 
sequence 5471, a sequence number is 15, a start reference point 
number 0, and an end reference point number 1. Similarly, as for 
the sequence 5472, those numbers are, in order, 14, 0, and 1, and 
as for the sequence 5473, 13, 0, and 1. The same map as FIG. 14 
is also shown in FIG . 15, viewed from the interpolation point number 
544 at ground level. 

[0118] By referring to both FIGS. 14 and 15, it is known that 

the road 547 crosses over the road 546, and a left lane of the 
road 547 is jammed. Here, both the map and vehicle models 548 
may be two- and three-dimensionally displayed. 

[0119] The above processing done to the function to present 

traffic jam information is similarly done to other functions shown 
in FIGS. 9 and 10. By taking the function to present 
under-cons truct ion information as an example, referred to is the 
under-cons truct ion information ID, and arranged on the road is 
a polygon such as a sign and figure indicative of construction. 

[0120] In step SI 34 , the map data arranging part 4 checks whether 

every information read by the communications part 7 is now through . 
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If Yes, this is the end of subroutine step S13, and the procedure 
returns to the main routine of FIG. 3. If not yet, the procedure 
returns to step S132 to repeat the processing. After subroutine 
step S13 is through, the map data arranging part 4 forwards the 
5 resultant map data to the display 5. Then, the display 5 
accordingly displays a resultant map image thereon. 
[0121] FIG. 16 shows an exemplary map image generated through 

such processing as above described. In FIG. 16, there include 
a police car polygon, "jammed" signs, and cartoon-like figures 
10 indicative of construction appropriately placed on a 3D landscape 
with buildings. With such map image, the user can intuitively 
grasp various types of information without busily moving his/her 
eyes . 

[0122] Here, prior to describing subroutine step S133 about 

15 the detailed processing of the map data arranging part 4, the 
detailed structure thereof is described with reference to FIGS. 
17 and 18. 

[0123] FIG. 17 is ablock diagram showing the detailed structure 

of the map data arranging part 4 . In FIG. 17, the map data arranging 

20 part 4 includes an execution part 41 and a display data arranging 
part 42. The execution part 41 receives information each from 
the object model display information storage part 6, the input 
part 2, and the communications part 7, and executes the object 
model display information. The display data arranging part 42 

25 receives map data both from the execution part 41 and the map data 
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storage part 3 for data arrangement. 

[0124] The execution part 41 detects any interrupt event, and 

executes each corresponding command. Also, the execution part 
41 executes the object model display information so that object 
5 data is generated and forwarded to the display data arranging part 
42. The display data arranging part 42 accordingly arranges the 
object data on the map data for display on the display 5. 

[0125] Described next is the detailed structure of the execution 

part 41. FIG. 18 is a block diagram showing such structure, 
10 including a control part 411, and an interpretation part 412. 

[0126] The control part 411 receives information each from the 

object model display information storage part 6, the input part 
2, and the communications part 7 , and per forms control responsively 
to each event. By the interpretation part 412, responding to an 
15 object model creation request or an object model attribute change 
request forwarded from the control part 411, the object model 
display information is interpreted and object data is generated. 
Thus generated object data is outputted to the control part 411. 

[0127] Described next is subroutine step S133 in FIG. 5 about 

20 the detailed processing in the map data arranging part 4. A 
flowchart of FIG. 19 is now referred to. 

[0128] In step S91 in FIG. 19, the execution part 41 detects 

an interrupt event from the communications part 7, the input part 
2, or a timer. Typically, the procedure repeats step S91, unless 
25 otherwise interrupted, until the execution part 41 detects any 
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interrupt event. 

[0129] Once detected, in step S92, the execution part 41 

analyzes the detected event, and executes processing corresponding 
thereto. In this example, an event is classified into fourt 
categories: update, display condition fire, creation, and 
attribute change. If the event is analyzed as being an update 
event, the procedure goes to step S94. Similarly, the procedure 
goes to step S95 with a display condition fire event, to step S96 
with a creation event, and to step S98 with an attribute change 
event . 

[0130] In step S94 (update event) , the execution part 41 reads 

an updated version of the object model display information from 
the communications part 7 for storage into the object model display 
information storage part 6. The updated version may entirely or 
partially correspond to the stored ob j ect model display information . 
With the processing completed, ■^fer^-4rS-~ ; ^ subroutine step 

S133 ends, and the procedure returns to the flow of FIG. 5. 
[0131] In step S95 (display condition fire event) , the execution 

part 41 analyzes the contents of the display condition fire event, 
and accordingly changes the display condition in setting. With 
this processing completed, -£rk4rie^e^ subroutine step S133 

ends, and the procedure returns to the flow of FIG. 5. 
[0132] In step S96 (creation event) , the control part 411 reads 

the ob j ect model display information about the corresponding ob j ect 
model from the object model display information storage part 6, 
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and transmits the information to the interpretation part 412 to 
ask for object model creation. Then, in step S97, the control 
part 411 has the interpretation part 412 interpret thus transmitted 
information about ob j ect model shape and behavior in time and space 
(typically, information described in simplified language and 
functions) . Thereafter, the object model display condition is 
set and a— display processing is carried out. Such object model 
display information is already described in structure and manner 
to be executed. 

[0133] Next, in step S99, the execution part 41 forwards an 
interpretation result about the object model display information 
for arrangement on the map data. With this processing completed, 
-fcrf^4re~4-e~^ subroutine step S133 ends, and the procedure 

returns to the flow of FIG. 5. 

[0134] In step S98 (attribute change event) , the control part 

411 asks the interpretation part 412 to per form processing to change 
the object model attribute such as position and size. Then, in 
step S99, the execution part 41 performs such processing as 
described above. With such processing completed, 4~k^f>™^s™^^^ 
-e-£ subroutine step S133 ends, and the procedure returns to the 
flow of FIG. 5. 

[0135] Described next is step S99inFIG. 19 about how the display 

data arranging part 42 generates a map image. First, described 
is a case where a resultant map image is of a 2D landscape. FIG. 
20 is a diagram showing the detailed structure of the display data 
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arranging part 42 for such case. In FIG. 20, the display data 
arranging part 42 includes a 2D object model creation part 145, 
and a 2D data arranging part 146. 

[0136] The 2D ob j ect model creation part 145 receives the obj ect 

5 model display information from the execution part 41, and creates 
a 2D object model. The 2D data arranging part 146 receives thus 
created 2D object model and 2D map data from the map data storage 
part 3, and generates a map image by arranging those in accordance 
with 2D coordinates included in each of those. 

10 [0137] Described next is a case where a resultant map image 

is of a 3D landscape. In such case, there is no need for an object 
model created from the object model display information and map 
data stored in the map data storage part 3 to be 3D. Exemplified 
now is a case where the data provided by the execution part 41 

15 to the display data arranging part 42 is 3D, and the data by the 
map data storage part 3 is 2D, and a resultant map image is of 
a 3D landscape. 

[0138] FIG. 21 is ablock diagram showing the detailed structure 

of the display data arranging part 42, which receives 3D data from 
20 the execution part 41 and 2D map data from the map data storage 
part 3. A resultant map image generated thereby is of a bird's 
eye view. 

[0139] In FIG. 21, the display data arranging part 42 includes 

a bird' s eye view transformation part 141, a 3D obj ect model creation 
25 part 142, and a 3D data arranging part 143. 
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[0140] The bird's eye view transformation part 141 receives 

the 2D map data from the map data storage part 3, and then transforms 
the data to a bird's eye view. A technique for transforming 2D 
data to a bird' s eye view is disclosed in detail in "Development 
5 of a Car Navigation System with a Bird' s-eye View Map Display" 

( Society of Automotive Engineers of Japan, Inc, Papers, 962 1996-5), 
for example. Next below, a technique for transforming 2D data 
to a bird's eye view is described. 

[0141] FIG. 22 is a diagram demonstrating a technique for 

10 creating a bird' s eye view by subjecting 2D map data to perspective 
transformation. In FIG. 22, a point V(Vx, Vy, Vz) indicates 
viewpoint coordinates. A point S(Sx, Sy) indicates coordinates 
of a bird's eye view image on a monitor, and a point M(Mx, My, 
Mz) indicates coordinates on a 2D map image. Here, since the map 
15 data is 2D data, Mz is 0. Points Ex, Ey, and Ez each indicate 
a relative position to the point M in the viewpoint coordinates 
system. A reference character 6 denotes a look-down angle, while 
<f> indicates a direction angle of viewpoint . A reference character 
DS indicates a theoretical distance between the viewpoint and the 
2 0 image. 

[0142] Here, with the viewpoint coordinates V(Vx, Vy, Vz), 

look-down angle 0 , and direction angle (f> specified in value, the 
coordinates S (Sx, Sy) of the bird' s eye view image can be calculated 
with respect to the coordinates M(Mx, My, Mz) on the 2D map image. 
25 An equation (1) therefor is as follows: 
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[0143] With the above equation (1), for example, the bird's 
eye view transformation part 141 transforms the 2D map data provided 
by the map data storage part 3 to a bird's eye view. The bird's 
eye view of 3D data is forwarded to the 3D data arranging part 
5 141 . 

[0144] The 3D object model creation part 142 receives the 3D 

data, and then creates a 3D object model with the processing in 
subroutine step S133 in FIG. 5. Thus created 3D object model is 
forwarded to the 3D data arranging part 143. 
10 [0145] The 3D data arranging part 143 arranges thus received 

3D data and object model data together for output to the display 
5. FIG. 23 shows exemplary data thus generated and displayed on 
the display 5. 

[0146] In FIG. 23, there include 3D objects indicative of 

15 construction and a parking lot being full . In FIG. 23, presumably, 
these object models are 3D of a type changing in shape with varying 
viewpoints even if looked at. as 2D. 

[0147] Exemplified now is a case where the data provided by 

the execution part 41 is 3D, and the data by the map data storage 
20 part 3 is 2D, and a resultant map image is of a 3D landscape, which 



51 



looks different from the bird's eye view. 

[0148] FIG. 24 is ablock diagram showing the detailed structure 

of the display data arranging part 42, which receives 3D data from 
the execution part 41 and 2D map data from the map data storage 
5 part 3. A resultant map image generated thereby is of a 3D landscape, 
which is different from a bird's eye view. 

[0149] In FIG. 24, the display data arranging part 42 includes 

a 3D map data generation part 147, the 3D object model creation 
part 142, and the 3D data arranging part 143. 

10 [0150] In FIG. 24, the 3D object model creation part 142 and 

the 3Ddata arranging part 143 are similar in structure and operation 
to those in FIG. 21. Thus, the 3D map data generation part 147 
is mainly described in structure and operation below. 
[0151] FIG. 25 is ablock diagram showing the detailed structure 

15 of the 3D map data generation part 147. In FIG. 25, the 3D map 
data generation part 147 includes a height /width information supply 
part 1471, and a 3D polygon creation part 1472. [0152] 
The height/width information supply part 1471 supplies 
information about height and width to the 3D polygon creation part 

20 1472 responding to 2D map data provided by the map data storage 
part 3 . The 3D polygon creation part 1472 then creates a 3D object 
model . 

[0153] The height/width information supply part 1471 analyzes 

the 3D shape of a road, for example, with the help of the link 
25 type (e.g., side-road link, elevated link) and information about 
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a branching node included in the 2D map data, typically by applying 
a predetermined pattern. With the analyzed result, the 
height/width information supply part 1471 adds information about 
height and width to the 2D data of the road, for example, so as 
5 to generate 3D map data. 

[0154] The 3D polygon creation part 1472 receives thus generated 

3D map data, and creates a 3D object model with a general technique 
therefor. In the above manner, the display data arranging part 
42 of FIG. 24 generates a map image of 3D landscape, which looks 

10 different from a bird's eye view. 

[0155] Exemplified next is a case where the data provided by 

the execution part 41 to the display data arranging part 42 is 
2D, and the data by the map data storage part 3 is 3D, and a resultant 
map image is of a 3D landscape. 

15 [0156] FIG. 2 6 is a block diagram showing the detailed structure 

of the display data arranging part 42, which receives 2D data from 
the execution part 41 and 3D map data from the map data storage 
part 3. A resultant map image generated thereby is a map image 
of 3D landscape. 

20 [0157] In FIG. 26, the display data arranging part 42 includes 

a 2D object model creation part 145, a 2D/3D coordinate 
transformation part 144, and the 3D data arranging part 143. 
[0158] In FIG. 26, the 2D ob j ect model creation part 14 5 receives 

2D data from the execution part 41, and then creates a 2D object 

25 model by going through subroutine step S133 in FIG. 5. 
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[0159] To be specific, as already described, a plurality of 

image files are prepared as 2D shape information included in the 
ob j ect model display information . FIG. 27 is a diagram exemplarily 
showing several image files prepared as such. In FIG. 27, images 
are classified into "accident", "under-construction", and 
" j ammed" . Such image type corresponds to the ob j ect model display 
information, and is further classified into "close-range", 
"medium-range", and "long-range" . 

[0160] The 2D object model creation part 145 first determines 

the image type by referring to the ob j ect model display information . 
The 2D object model creation part 145 then selects a distance range 
for the determined image type ej^^-from ainong ^e^e-" close-range", 
"medium-range", and "long-range". Here, as described above, the 
object model display information includes position information 
indicating the position of the object model by 3D coordinates. 
In FIG. 27, selecting a distance range for each image is based 
on a distance between such 3D coordinates and viewpoint coordinates . 
Therefore, typically, the 2D object model creation part 145 
calculates such distance to determine to which distance range the 
thus calculated distance applies. 

[0161] As for a resultant 2D object model, the 2D/3D coordinate 

transformation part 144 transforms 2D coordinates thereof to 3D 
coordinates based on the corresponding position information. 
Then, the resultant 3D object data is inputted into the 3D data 
arranging part 143. 



[0162] The 3D data arranging part 143 receives 3D map data from 

the map data storage part 3. The 3D data arranging part 143 then 
arranges the map data together with the 3D ob j ect model data provided 
by the 2D/3D coordinate transformation part 144 to generate a map 
5 image of 3D landscape. Thus generated map image is forwarded to 
the display 5. 

[0163] Here, in the display data arranging part 42 as above 

structured, the 2D object model created by the 2D object model 
creation part 145 is transformed to 3D data by the 2D/3D coordinate 

10 transformation part 144, and then arranged together with the 3D 
map data in the 3D data arranging part 143 . This is not restrictive, 
and the 2D/3D coordinate transformation part 144 may be omitted, 
and a 2D/3D image arranging part may be provided as an alternative 
to the 3D data arranging part 143. If this is the case, the 2D/3D 

15 image arranging part pastes a 2D object model created by the 2D 
object model creation part 145 onto a map image of 3D landscape. 
In more detail, the 2D/3D image arranging part first generates 
a map image of 3D landscape by transforming 3D map data to screen 
coordinates, calculates screen coordinates of a 2D object model, 

2 0 and arranges 2D data as it is on a resultant map image of 3D landscape . 
With such modified structure, an object model looks the same even 
if viewed from various positions , and is ^s^s-ie-¥e6-a 1 w a y s displayed 
the same. Therefore, better viewability is offered. 
[0164] FIG. 28 shows an exemplary map image of 3D landscape 

25 generated by the display data arranging part 42 of FIG. 26. In 
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FIG. 28, the map image has object models indicative of an 
construction displayed on the left side, an obj ect model indicative 
of a. accident in the middle, and object models indicative of a 
traffic jam on a road. As to those objects indicative of traffic 
5 jam, the size thereof is changed based on a distance from the 
viewpoint coordinates as described above, thereby adding depth 
to the map image of 3D landscape even if the object models are 
2D. 

[0165] Lastly, exemplified is a case where the data provided 

10 by the execution part 41 to the display data arranging part 42 
is 2D, and the map data by the map data storage part 3 is 2D, and 
a resultant map image is of a 3D landscape. 

[0166] If this is the case, the display data arranging part 

42 of FIG. 26 is additionally provided with the bird's eye view 
15 transformation part 141 of FIG. 21, or the 3D map data generation 
part 147 of FIG. 24, both of which convert 2D map data into 3D 
map data . Here, the components included therein operate similarly 
to those described above. 

[0167] In such a case as a map image of 3D landscape being 

20 generated from 2D data, the 2D data stored in the object model 
display information storage part 6 is less in amount than 3D data. 
Therefore, if storing object model data varying in type, the object 
model display information storage part 6 can store the larger number 
of types, and if storing the same type of object model data, the 
25 capacity thereof can be reduced. 
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[0168] Further, in such a case as a map image of 3D landscape 

being generated from 2D data, the user can intuitively understand 
information even if object models are 2D. For example, the user 
does not have to stop his/her vehicle to understand what is going 
on on the way to his/her destination as he/she can easily and 
intuitively understand what the displayed ob j ect models indicate . 
[0169] FIG. 29 is an exemplary map image of 3D landscape on 

which 2D object models indicative of a traffic jam are arranged. 
As shown in FIG. 29, with a plurality of object models indicative 
of a. traffic jam, the user can intuitively grasp that the road 
ahead is jammed. 

[0170] FIG. 30 is another exemplary map image of 3D landscape 

on which 2D objects indicative of an accident are arranged. As 
shown in FIG. 30, with a plurality of object models indicative 
of an accident, the user can intuitively grasp that accidents are 
occurred on the road ahead. 

[0171] Similarly, with object models indicative of 

construction displayed on the map image of 3D landscape, the user 
can intuitively grasp that the road ahead is under construction. 
Typically, by changing the size of those objects on the map image, 
the user intuitively understands how far the construction work 
continues . 

[0172] FIG. 31 is still another exemplary map image of 3D 

landscape on which 2D objects indicative of construction are 
arranged. FIG. 32 shows the same map image as FIG. 31, but the 
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viewpoint is different and closer. As such, by changing the size 
of object models in the map image as the viewpoint changes, the 
user can easily specify which road is now under construction. 
[0173] ■■{■Second Embodiment-)- 

FIG. 33 is a block diagram showing the structure of a 
navigation device according to a second embodiment of the present 
invention. In FIG. 33, the navigation device includes the input 
part 2, the map data storage part 3, the map data arranging part 
4, the display 5, the object model display information storage 
part 6, the communications part 7, the position detection part 
9, a route selection part 10, and a guiding part 11. 
[0174] Herein, the input part 2, the map data storage part 3, 

the map data arranging part 4, the display 5, the object model 
display information storage part 6, and the communications part 
7 operate e4^e^-e~similarly to those in the map display device of 
FIG. 1. Also, the position detection part 9, the route selection 
part 10, and the guiding part 11 herein operate similarly to those 
in the navigation device of FIG. 67. 

[0175] Such structured navigation device of FIG. 33 can be 

realized in a general computer system as is the map display device 
of FIG. 1. The structure of a navigation device realized as such 
is shown in FIG. 34. 

[0176] In FIG. 34, the navigation device includes a CPU 342, 

ROM 343, RAM 344, an output part 345, an input part 346, a position 
detection part 34 9, and a communications part 534 348 , all of which 
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are interconnected by a bus. Here, presumably, the ROM 343 and 
the RAM 344 possibly include a storage device with an external 
storage medium-^tt^r&f^f similar to the ROM 333 and the RAM 334 
of FIG. 2. 

[0177] The position detection part 349 is composed of a GPS, 

radio beacon receiver, vehicle-speed sensor, angular velocity 
sensor, absolute azimuth sensor, and the like. In the case that 
the position detection part 349 is composed of a radio or optical 
beacon receiver, and a radio or optical beacon signal includes 
any external information, the communications part -3-3-8- 34 8 may be 
omitted. If so, the position detection part 349 functionally 
substitutes therefor . 

[0178] In FIG. 34, the CPU 342 operates in accordance with a 

program stored in the ROM 343 and/or the RAM 344. Thus, the map 
data arranging part 4, the route selection part 10, and the guiding 
part 11 of FIG. 33 maybe functionally realized by each corresponding 
program. In such a case, a storage medium typically storing such 
program is implemented in the navigation device. The program may 
be -^e-^e^transmittecl over a communications circuit. 
[0179] The ROM 343 typically includes the map data storage part 

of FIG. 33, or the RAM 344 may do so entirely or partially . Similarly, 
the RAM 34 4 typically includes the obj ect model display information 
storage part 6, or the ROM 343 may do so. 

[0180] As such, the navigation device of FIG. 33 according to 

the second embodiment operates e^mee-^-similarly to the map display 



device of FIG. 1 according to the first embodiment, except for 
some~<3"e*sg^^ components operating similarly to those 

in the conventional navigation device. Next below, by referring 
to FIG . 35, the basic operation of the navigation device is described 

[0181] FIG. 35 is a flowchart showing a basic flow of processing 

in the navigation device of this embodiment. In step S51 of FIG. 
35, with a user-designated destination and a map region provided 
by the input part 2, and with a vehicle position provided by the 
position detection part 9, the route selection part 10 accordingly 
performs a route search. A result obtained thereby is outputted 
to the guiding part 11. 

[0182] Next, in step S52, the guiding part 11 requests the map 

data arranging part 4 for a map data arrangement to display a map 
which covers an area corresponding to the vehicle position detected 
by the position detection part 9. In step S53, the map data 
arranging part 4 reads map data from the map data storage part 
3. In step S54, the guiding part 11 reads communications 
information from the communications part 7 for output to the map 
data arranging part 4. In subroutine step S55, the map data 
arranging part 4 creates an object model according to the received 
communications information and information stored in the object 
model display information storage 6 for arrangement on the map 
data . 

[0183] Here, the processing in step S53 to subroutine step S55 
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in FIG. 35 roughly corresponds to that in step Sll to subroutine 
step S13 in FIG. 3. Accordingly, the processing in subroutine 
step S55 in FIG. 35 also corresponds to the processing in FIG. 
5. Thus, such processing is not described here again. 
[0184] Lastly, in step S56 in FIG. 35, the guiding part 11 keeps 

providing guidance until the user reaches his/her destination. 
Thus, the procedure returns to step S52 to repeat the processing 
until the guiding part 11 determines the user has fefH4f^~~reached 
his/her destination. 

[0185] As is known from the above, the navigation device of 
the second embodiment is also capable, at time of guidance, of 
making the user intuitively understand information without busily 
moving his/her eyes. Further, in the navigation device, the 
capacity of a storage medium for object model is reduced with a 
lower -^e-s-e — amount of incoming information. 
[0186] -(-Third Embodiments 

FIG. 36 is a block diagram showing the structure of a 
map display device of a third embodiment according to the present 
invention. In FIG. 36, the map display device includes the input 
part 2, the map data storage part 3, the map data arranging part 
4, the display 5, the object model display information storage 
part---5- 6, the communications part 7, and a time information storage 
part 8 . The map display device of FIG. 36 is additionally provided 
with a ^e~time information storage part 8 compared with the one 
in FIG. 1. Described next below is the time information storage 



part 8 about its structure and operation. 

[0187] The time information storage part 8 is composed of an 

optical disk (e.g., CD, DVD), hard disk, semiconductor memory card 
(e.g., SD card) , and the like, and stores time information having 
time and place interrelated therein . That is, the time information 
indicates a mobile unit, for example, location lre^e^4:f^~where at 
what time in a table or equations. Such time information includes 
a timetable (e.g., train, bus, airline, ferry), service schedule, 
diagram, and the like. The time information storage part 8 may 
store in advance such time information, or may receive time 
information via the communications part 7 for storage or for 
updating -ts^krfe^-the previously stored time information therewith. 
[0188] FIG. 37 shows exemplary time information stored in the 

time information storage part 8 of FIG. 36. The time information 
inFIG. 37 is about a train timetable, and data therein is represented 
in a tree structure. The train timetable data herein covers data 
about two railway companies of KT and KH, specifically indicating 
which train arrives at and departs from which station on the way 
to its destination. Each station is assigned a station ID number, 
and is positionally defined by latitude and longitude. ^d- r -ee-e^ 
Each train is also indicatedby arrival and departure times together 
with its destination. The time information storage part 8 outputs 
data requested by the map data arranging part 4 . 
[0189] FIG. 38 is a flowchart showing the operation of the map 

data arranging part 4 of FIG. 36. Here, steps S41, S43, and S13 



in FIG. 38 are almost the same as steps Sll and S12, and subroutine 
S13 in FIG. 3, respectively. Therefore, any step different from 
that in FIG. 3 is now mainly described. 

[0190] In subroutine step S42 in FIG. 38, the map data arranging 

part 4 reads time information from the time information storage 
part 8 , and goes through processing to display the time information . 
Described next is the process of subroutine step S42. 
[0191] FIG. 39 is a flowchart showing the detailed process of 

subroutine step S42 in FIG. 38. In step S421 in FIG. 39, the map 
data arranging part 4 reads time information relevant to a map 
display area from the time information storage part 8. In more 
detail, the map data arranging part 4 may see which station is 
included in the map display area on the basis of latitude and 
longitude so as to extract only relevant time information. Another 
possibility is that G^- 7 — any station ID number found in the map 
display area is referred to for extracting only applicable time 
information. For example, in the train timetable of FIG. 37, the 
map display area covers Z r X r and Y stations of the KT railway 
company . 

[0192] Next, in step S422 , the map data arranging part 4 selects 

any train to be displayed by referring to time information currently 
relevant to the map display area. The map data arranging part 
4 specifically refers to time information which is in a 
predetermined time range from the current time. Then, the map 
data arranging part 4 specifies every applicable train passing 



through the map display area during the time range. 
[0193] Assuming that it is now ^e---8:00 a.m., the map data 

arranging part 4 specifies any train which reaches at and departs 
from X, Y, and Z stations around 8:00 a.m. A technique therefor 
5 is specifically described by referring to FIG. 40. 

[0194] FIG. 40 is a schematic map showing which train reaches 

at what station at what time. In FIG. 40, an A train is considered 
applicable as it leaves the Y station at 7:58 a.m., and reaches 
at the Xstationat 8:03a.m. Similarly, a Strain is also considered 

10 applicable as it leaves the Z station at 7:59 a.m., and reaches 
at the Y station at 8:02 a.m. As such, the map data arranging 
part 4 specifies every possible train passing through the map 
display area around 8:00a.m. In this sense, limited express trains 
are better to be positionally specified also in the timetable around 

15 that time, that is, which limited express passes which station 
at what time. Here, such passing time for the limited express 
trains is not necessarily provided as is capable of being estimated 
esfe^a^re-from what time the train reaches at and departs from 
which station. Also, the train timetable may be a train diagram 

20 for controlling the train service, or represented in equations 
for defining every train by time and location. 

[0195] In step S423 in FIG. 39, the map data arranging part 

4 calculates display coordinates for every selected train from 
the corresponding time information. For example, the A train of 
25 FIG. 40 serves for a section between the X and Y stations, and 
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the timetable tells that a required time therefor is 5 minutes. 
The timetable also tells that the A train is at a distance of 2/5 
from the Y station at 8:00 a.m. as having left the Y station 2 
minutes before. Accordingly, the map data arranging part 4 
calculates the position in latitude and longitude, and defines 
that position ™e^e™as the display coordinates for the A train. 
Display coordinates for the B train 4re~~ are calculated in a similar 
manner. Here, the above description is not surely restrictive, 
and the timetable may be of a type showing times previously 
calculated for each position. Further, in order to calculate 
display coordinates for a specific train, a train diagram and 
equation, for example, may be referred to. As such, the map data 
arranging part 4 generates display information such as train 
position and type. 

[0196] Next, in subroutine step S13, thus generated display 

information and information stored in the object model display 
information storage part 6 are both referred to for creating an 
object model, which is arranged on the map data. The detailed 
process of subroutine step S13 is similar to that of subroutine 
step S13 in FIG. 5. 

[0197] Specifically, in a case where the object model display 

information is about a train and represented in such functions 
as shown in FIGS. 9 and 10, the map data arranging part 4 also 
reads corresponding display information, and then accordingly 
calculates space coordinates on the map data. The map data 



arranging part 4 then creates a train polygon and sign applicable 
to the train type (e.g., which railway company, whether express 
or local) in an intermediate buffer, and arranges those in the 
map space . 

[0198] The map data arranging part 4 then forwards a resultant 

map image to the display 5. The display 5 accordingly displays 
a map image showing object models in the shape of trains (e.g., 
train polygon and sign) at each appropriate position. Therefore, 
the user in an actual train can understand more intuitively, 
together with the map image, where his/her train is **e-w~~ currently 
and to which direction it is heading. 

[0199] In the case that time information relevant to a map 

display area is externally available via the communications part 
7, step S421 in FIG. 39 may be omitted. Further, when position 
information about trains, for example, is externally available 
via the communications part, steps S421 and S422 in FIG. 39 may 
be omitted. 

[0200] Here, if the map display device of this embodiment is 

additionally provided with the position detection part 9, the route 
selection part 1 0 , and the guiding part 11 , reali zed is a navigation 
device functioning similar to the present map display device. 
Further, the time information storage part 8 provided to the present 
map display device may be also provided to the navigation device 
of the second embodiment, making the navigation device function 
similarly to the present map display device. 



[0201] Note that, the map display device of the third embodiment 

may or may not. entirely or partially include the functions unique 
to the map display device of the first embodiment^ — enr-f ™»^e- . 
Similarly, the navigation device having the present map display 
device applied may or may not entirely or partially include the 
functions unique to the navigation device of the second embodiment™ 

[0202] -{-Fourth Embodiments 

FIG. 41 is a block diagram showing the structure of a 
map display device according to a fourth embodiment of the present 
embodiment. In FIG. 41, the map display device includes the input 
part 2, the map data storage part 3, the map data arranging part 
4, the display 5, the object model display information storage 
part 6, the communications part 7, and a ticket information storage 
part 12. Here, the ticket information storage part 12 may be 
implemented by a semiconductor card or magnetic card 
detachable/attachable to the map display device. 
[0203] The map display device is similar in structure to that 

in FIG. 1 except additionally including the ticket information 
storage part 12. Thus, any constituent found in FIG. 1 is denoted 
by the same reference numeral , and not described again . Note herein 
that, unlike the map display device of FIG . 1 wherein communications 
is not necessarily two-way, communications between the 
communications part 7 and an external automated fare-collection 
center or faregate (both not shown) never fails to be two-way, 
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and so is data communications between the map data arranging part 
4 and the communications part 7. Also, the map display device 
herein operates as a terminal of an automated fare-collection 
system, and thus the map data arranging part 4 operates differently 
as described next below. 

[0204] FIG. 42 is a flowchart showing the processing carried 

out by the map data arranging part 4, which operates as a terminal 
of an automated fare-collection system. In step S611 in FIG. 42, 
the map data arranging part 4 reads map data from the map data 
storage part 3. Then, in step S612, the map data arranging part 
4 reads f aregate information e&e^transmitted from each -fe^ee^fere-s- 
faregate or an automated fare-collection center. Typically, the 
faregate information includes faregate IDs and position 
coordinates for each of the faregates. In subroutine step S613, 
the map data arranging part 4 refers to thus read faregate 
information and information stored in the object model display 
information storage part 6, and creates a faregate polygon for 
arrangement on the map data. 

[0205] Such processing as above each correspond to those in 

FIG. 3. That is, steps S611, S612, and S613 in FIG. 42 are the 
same as steps Sll and S12, and subroutine step S13 in FIG. 3, 
respectively, and are not described again. 

[0206] Here, the faregate information in FIG. 42 may not 

necessarily be communications information, but merely be general 
landmark information, or may include information about fares. 
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Therefore, the faregate information is not necessarily read from 
the communications part 7, and an object model may be created only 
from the information found in the object model display information 
storage part 6 in subroutine step S613. In such a case, step S612 
is omitted. 

[0207] Next, in step S614 in FIG. 42, the map data arranging 

part 4 determines whether any via-station interrupt event 
information is forwarded from the communications part 7. 
Specifically, once the map display device carried along by a user 
^se4- passes through a faregate at a station, ^^^s^^e^e-a-"^^ 
the via-station interrupt event information is transmitted from 
the faregate or the automated fare-collection center. The 
via-station interrupt event information includes entrance event 
information or exit event information, which will be described 
later. The map data arranging part 4 determines whether the 
via-station interrupt event information is received by the 
communications part 7 . Ifnot yet, this is the end of the procedure . 
Note that, the processing in FIG. 42 is typically executed 
repeatedly at predetermined time intervals. If the information 
is received, on the other hand, the procedure goes to step S615. 

[0208] In step S615, the map data arranging part 4 analyzes 

the received via-station interrupt event information. If 
analyzed #^™as the entrance event information, the map data 
arranging part 4 executes the corresponding object model display 
information stored in the object model display information storage 



part 6, and then displays a predetermined symbol or object model 
on the display 5. Typically, displayed is a faregate symbol 
carrying information about the user' s traveling section, payment 
history, fare, and the like. 

[0209] FIG. 43 is a diagram showing exemplary symbols to be 

displayed in step S615. In FIG. 43, shown are a faregate symbol 
1001 and fare information symbol 1002. The faregate symbol 1001 
is typically displayed together with a map image at a position 
of a faregate corresponding to the fare information symbol 1002. 
For example, when the exit event information is received, the fare 
information symbol 1002 indicates from which station to which 
station the user traveled, and a fare for the section. Here, the 
fare may be calculated by the map display device with reference 
to a predetermined table, or the map display device may transmit 
information about the user' s traveling section to the automated 
fare-collection center, for example, and ^ee^-i-v-es-" receive a 
calculated result therefrom. 

[0210] Note that, prior to displaying such symbols, ticket 

purchase/use processing in subroutine step S616, which will be 
later described, may be carried out. That is, step S615 may be 
through before or at the same time as subroutine step S616. 
[0211] Next, in subroutine step S616, when the entrance event 

information is received first and then the exit event information, 
and if a predetermined condition is satisfied, the map data 
arranging part 4 carries out the ticket purchase/use processing. 
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Here, the ticket varies m type, and may be a pass, a ticket strip, 
and the like . The pass here is the right to travel in a predetermined 
section for a predetermined time period, or data indicating such 
right. The ticket strip is the right to travel in a predetermined 
fare section for the predetermined number of times, or data 
indicating such right. The map data arranging part 4 typically 
requests, via the communications part 7, the automated 
fare-collection center for -a—charge processing. The automated 
fare-collection center first identifies the user of the map display 
device, and then accordingly executes the charge processing in 
a predetermined manner. Described next is the process of 
subroutine step S616. 

[0212] FIG. 44 is a flowchart showing the detailed process of 

subroutine step S616 in FIG. 42. In step S6161 in FIG. 44, the 
map data arranging part 4 stores in a predetermined region a f aregate 
ID, which is assigned to each f aregate . As described in the 
foregoing, the faregate ID is typically included in information 
received by the communications part 7 . 

[0213] In step S6162, the map data arranging part 4 determines 

whether the faregate having the faregate ID stored in step S6161 
is used as an exit. If Yes, the procedure goes to step S6163™. 
e^e^w-iee- Otherwise, this is the end of subroutine step, and the 
procedure returns to the process of FIG. 42. 

[0214] In step S6163, the map data arranging part 4 refers to 

ticket information stored in the ticket information storage part 
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12 to see what is the user' s traveling section indicated by the 
faregate ID. Determined thereby is whether a pass can be used 
for the section. If usable, this is the end of subroutine step, 
and the procedure returns to the process of FIG. 42. Displayed 
here may be a message and a cartoon telling the user that the pass 
was used. If not usable, the procedure goes to step S616. Here, 
considered may be a case that no pass has been purchased yet, the 
pass is not usable for the section, or the pass has been expired. 
[0215] Specifically for the case that the pass has been expired, 

the map data arranging part 4 may encourage the user to purchase 
another with a message displayed on the display 5. Even if the 
pass is still valid,, but will expire soon, the map data arranging 
part 4 may warn the user also with a message. 

[0216] FIG. 45 is a diagram showing exemplary ticket information 

stored in the ticket information storage part 12. In FIG. 45, 
the ticket information includes ticket strip information 620 and 
pass information 630. For protection against tampering, such 
ticket information is preferably stored in a secured region wfee^e 
f^e — which is not user accessible with normal operation. 

Alternatively, the ticket information may be encrypted, and a 
decryption key may be stored in the secured region. Typically, 
such secured region is provided in an ID card inserted into the 
device. Further, the faregates and automated fare-collection 
center may hold the ticket information for distribution in response 
to a request by the map display device. 
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[0217] Here, the ticket strip information 620 includes a ticket 

strip ID 621, an entrance ID 622, an exit ID 623, a fare 624, and 
-fef*e— a remained number of times 625. In the remained, number of 
times 62 5 -Me^e, the ticket strip information 62 0 may include an 
5 expiration date . The pass information 63 0 includes a pass ID 631, 
an entrance ID 632, an exit ID 633, a fare 634, and an expiration 
date 635. Here, the ticket strip ID 621 and the pass ID 631 are 
each can identification number assigned to the ticket strip 
information and pass information, respectively, transmitted from 
10 the automated fare-collection center or the faregates. The 
entrance IDs 621 and 631 each correspond to the faregate ID as 
an entrance, and the exit ID 622 and 632 to the faregate ID as 
an exit. 

[0218] The ticket information is not generated until 

15 pass/ticket strip purchase processing is w^fe-executed, and thus 
there is no data at device activation. The ticket information 
may be plurally included, and may include information about any 
other type of ticket. 

[0219] Next, in step S6164 in FIG. 44, the map data arranging 

2 0 part 4 determines whether the ticket strip is usable for the section . 
If usable, the procedure goes to step S6165 .7-fr*ew±ee Otherwise, 
the procedure jumps to step S6166. Here, considered may be a case 
that a fare for the section exceeds that of the ticket strip, or 
the ticket strip has feeefr-already expired. 
25 [0220] In the case that the ticket strip has l^e^-expired or 
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the remaining number of times is 0, the map data arranging part 
4 may encourage the -ts^e— user to buy a pass with a message displayed 
on the display 5. Even if the ticket strip is still usable., but 
will expire soon or the remaining number of times is approaching 
0, the map data arranging part 5 may also display a message on 
the display 5. 

[0221] In step S6165, the map data arranging part 4 executes 

processing for using a ticket strip . To be specific, the remaining 
number of times 625 in the ticket strip information 620 is 
decremented by 1 . Here, once the remaining number of times-^eae^ee 
reaches 0, the ticket strip information 62 0 may be deleted or 
initiated. This is the end of subroutine step S616 in FIG. 44, 
and the procedure returns to the process in FIG. 42. Here, as 
is for the pass, a message and a cartoon may tell the user that 
the ticket strip was used. 

[0222] In step S6166, the map data arranging part 4 opens a 

dialog box through which the user can determine whether he/she 
purchases a pass or a ticket strip. If Yes, the procedure jumps 
to step S6168 .7 — e^re^e^ree Otherwise, the procedure goes to step 
S6187. Such dialog box is not restrictive, and the user may 
previously determine about his/her purchase, or a predetermined 
condition may be set in advance such as a pass is to be purchased 
with a higher priority. 

[0223] In step S 61 67 , the map data arranging part 4 goes through 

processing for purchasing a one-time ticket. To be specific, the 
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map display device refers to a predetermined table so as to calculate 
a fare for the user' s traveling section, and then transmits charge 
information for requesting the automated fare-collection center 
for charge processing. Alternatively, the map display device may 
transmit information about two applicable stations for the section 

(e.g., entrance ID 622 or 632 and exit ID 623 or 633 in FIG. 45) 
as charge information to the automated fare-collection center, 
and request for fare calculation and charge processing . Typically, 
the charge information includes a unique identification number 
for identifying the user of the map display device. 

[0224] The automated fare-collection center responsively 

executes the charge processing in a predetermined manner after 
identifying the user from the identification number assigned to 
the map display device, for example. Here, as for the charge 
processing, a fare is charged the user' s bank account every time 
the charge processing is executed or collectively at the end of 
the month. Another possibility is that Q-£~ r the charge information 
is written into an IC card or a prepaid card inserted into the 
map display device. The procedure then returns to the process 
in FIG. 42. 

[0225] In step S6168, the map data arranging part 4 executes 

processing for purchasing the pass or ticket strip determined in 
step 36166. The fare calculation and charge processing are 

the same as those in step S6167, and thus not described again. 
The procedure then returns to the process in FIG. 42. 
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[0226] In step S-b4-£ S617 in FIG. 42, the map data arranging 

part 4 determines whether every object model display information 
has been through. If not yet, the procedure returns to the process 
in step S 61 4 * T ~e4^e^^4^e Otherwise , this is the end of the procedure . 

[0227] Described next is the operation of such map display 

device with reference to FIG. 46. FIG. 46 is a diagram showing 
information transmitted by the automated fare-collection center 
in a case where the user uses a train with the map display device 
carried along. In FIG. 46, reference numerals 376 each denote 
4~&e- a user, and a reference numeral 375 denote s—e^e a map display 
device which is a take-i t-wi th-you type computer. 

[0228] In FIG. 46, presumably, the user 376 carrying along the 

map display device 375 enters an A station from a faregate 374 
to catch a train. Then, entrance event information 372 is 
transmitted from the automated fare-collection center, the 
faregate, or the like . The entrance event information 372 includes 
flag information, a faregate ID, and information about faregate 
position. When the user enters the faregate, FLG = 1 is set to 
the flag information. Each faregate ID is assigned an 
identification number, and the one in the A station is set to 1. 
The information about faregate position includes coordinates (XI, 
Yl ) defining the position by latitude and longitude . Once £-eeei^e4 
such information is received, the map display device 375 makes 
the display 5 display predetermined information such as payment 
history and a fare as already described in step S615. 
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[0229] Next, presumably, the user 376 carrying along the map 

display device 375 reaches his/her destination, that is, aBstation, 
and exits the B station from a faregate 373. Then, exit event 
information 371 is transmitted from the automated fare-collection 
center, the faregate, or the like. The exit event information 
371 is similar to the entrance event information 372, but flag 
information set thereto is FLG = 0, the faregate ID assigned to 
the B station is 2, and the information about the faregate position 
is coordinates (X2, Y2). Once — ±^e^™e^v^4 such information is 
received, the map display device 375 makes the display 5 display 
such information as described in step S615 and subroutine step 
S616, and executes the charge processing. 

[0230] As is known from the above, the map display device of 

the fourth embodiment operates as a terminal of an automated 
fare-collection system so that better usability is offered to a 
user, and further, represents various information in a more 
intuitive manner so that better viewability is also offered to 
the user. 

[0231] Here, the map display device of this embodiment is 

described as being applied in an automated fare-collection system 
in stations. This is not restrictive, and any type of automated 
fare-collection system will be acceptable -^H-e-fe-f-i-rie , for example, 
an ETC (Electronic Toll Collection System) on highways. 
[0232] Here, if the map display device of this embodiment is 

additionally provided with the position detection part 9, the route 
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selection part 10 , and the guiding part 11 , reali zed is a navigation 
device functioning similar to the present map display device . That 
is, in the present map display device, differences from the 
navigation device of the second embodiment are that the 
communications part 7 performs two-way communications, and the 
map data arranging part 4 ^^efeft-fclv-operates differently. Thus, 
by structuring the navigation device of the second embodiment as 
such, realized is a navigation device functioning similar to the 
present map display device . Described in a fifth embodiment below 
is a case where such navigation device is mounted in a vehicle, 
and is applied to ETC. 
[0233] -(-Fifth Embodiment)- 

FIG. 47 is a block diagram showing the structure of a 
navigation device of the fifth embodiment of the present invention . 
In FIG. 47, the navigation device includes the input part 2, the 
map data storage part 3, the map data arranging part 4, the display 
5, the object model display information storage part 6, the 
communications part 7, the position detection part 9, the route 
selection part 10, and the guiding part 11. Here, the navigation 
device of FIG. 47 isnot provided with the ticket information storage 
part 12 as is the map display device of FIG. 41. However, when 
ticket type is--eet-i*t\e-fe>i-e' able to be estimated as is in the fourth 
embodiment, the ticket information storage part 12 maybe included. 
[0234] The navigation device of this embodiment is similar in 

structure to that in FIG. 33, and thus any constituent found in 
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FIG. 33 is denoted by the same reference numeral, and not described 
again . A difference from the navigation device of FIG. 33 is that, 
in the present navigation 

device, communications between the communications part 7 and an 
external automated toll-collection center or tollgate (both not 
shown) is two-way, and so is data communications between the guiding 
part 11 and the communications part 7 . Also, thepresent navigation 
device differently operates as a terminal of the automated 
toll-collection system. Other than that, the present navigation 
device is similar in basic operation to that of the fourth embodiment . 
Next below, the operation of the present navigation device is 
described . 

[0235] FIG. 48 is a flowchart showing the processing in the 

navigation device-™ operating as a terminal in an automated 
toll-collection system. In step S 62 1 in FIG . 48, a user-designated 
destination and map region to be displayed are provided by the 
input part 2. Then, in response to a vehicle position forwarded 
from the position detection part 9, the route selection part 10 
performs a route search, and a result obtained thereby is forwarded 
to the guiding part 11. Then, in step S622, the guiding part 11 
requests the map data arranging part 4 for a data arrangement. 
[0236] In step S623, the map data arranging part 4 reads map 

data from the map data storage part 3. This step corresponds to 
step S611 in FIG. 42. In step S624, the guiding part 11 reads 
ETC toll collection information transmitted from the automated 
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toll-collection center or tollgates. This step corresponds to 
step S612 in FIG. 42. In subroutine step S625, the map data 
arranging part 4 refers to thus read ETC toll-collection 
information and information stored in the object model display 
information storage part 6, and creates a tollgate polygon for 
arrangement on the map data. This step corresponds to subroutine 
step in FIG. 42. 

[0237] Then, in step S626, the map data arranging part 4 

determines whether there is any via-ETC interrupt event information 
from the communications part 7 . To be specific, once the navigation 
device passed through an ETC gate, transmitted from the automated 
toll-collection center or each of the tollgates is via-ETC 
interrupt event information. The via-ETC interrupt event 
information is almost the same as the via-station interrupt event 
information described in the fourth embodiment, but will be later 
described. The map data arranging part 4 determines whether the 
via-ETC interrupt event information is received by the 
communications part 7. If not yet, this is the end of procedure. 
Note that, the processing in FIG. 48 is typically executed 
repeatedly at predetermined time intervals. If the information 
is received, on the other hand, the procedure goes to step S627. 
Here, step S627 corresponds to step S614 in FIG. 42. 

[0238] In step S627, the map data arranging part 4 analyzes 

the received via-ETC interrupt event information. If analyzed 
4>h-a4r as 4^e- entrance event information, or both of the entrance 
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and exit event information, the map data arranging part 4 executes 
the corresponding object model display information stored in the 
object model display information storage part 6, and then displays 
a predetermined symbol on the display 5. Typically, displayed 
is a tollgate symbol carrying information about payment history, 
cumulative amount of tolls, and the like. Here, this step 
corresponds to step S615 in FIG. 42. 

[0239] FIG. 49 is a diagram showing exemplary symbols to be 

displayed in step S627. In FIG. 49, similarly to FIG. 43, shown 
are a tollgate symbol 1011 and toll information symbol 1012. The 
tollgate symbol 1011 is typically displayed together with a map 
image at a position of a tollgate corresponding to the 
above-described ETC toll-collection information. For example, 
after the entrance event information is received, the toll 
information symbol 1012 indicates highway information about the 
vehicle's entrance and exit located on a guided route, a toll for 
the section, and estimated arrival time and required time. Here, 
the toll may be calculated by the navigation device with reference 
to a predetermined table, or the navigation device may transmit 
information about the user' s driving section to the automated 
toll-collection center, for example, and^-^e-eHe^h^e^ receive a 
calculated result therefrom. 

[0240] As such, the navigation device of the fifth embodiment 

is additionally provided with the position detection part 9, the 
route selection part 10, and the guiding part 11 to the map display 
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device of the fourth embodiment. Accordingly, by utilizing a 
result obtained by a. route search, the navigation device can perform 
an estimation as above so that the user can be informed in advance. 
[0241] Next, in step S628, when received both the entrance and 
exit event information are received., the guiding part 11 typically 
requests, via the communications part 7, the automated 
toll-collection center for the charge processing. The automated 
toll-collection center first identifies the user of the navigation 
device, and then accordingly executes the charge processing in 
a predetermined manner . Here, this step corresponds to subroutine 
step S616 in FIG. 42. 

[0242] In step S629, the map data arranging part 4 determines 

whether every object model display information has been -^fe^e^g^r 
processed. If not yet, the procedure returns to the process in 
step S626. If Yes, the procedure goes to step S630. Here, 
step S630 corresponds to step S617 in FIG. 42. 

[0243] In step S630, the guiding part 11 determines whether 

the guidance is now completed, for example, whether the vehicle 
has reached its destination. If not yet, the procedure returns 
to step S622 to repeat the processing until the guiding part 11 
determines the vehicle~4r€ffi4rTf has reached its destination. 
[0244] Described next is the specific operation of such 

navigation device with reference to FIG. 50. FIG. 50 is a diagram 
showing information transmitted by the automated toll-collection 
center in a case where the present navigation device is used as 
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an ETC terminal. In FIG. 50, reference numerals 407 each denote 
the navigation device which is mounted on a vehicle. Here, the 
information transmitted from the automated toll-collection center 
in FIG. 50 is almost the same as the information transmitted from 
the automated fare-collection center in FIG. 46. 
[0245] In FIG. 50, presumably, the vehicle-mounted navigation 

device 407 passes through a tollgate such as an ETC-dedicated gate 
to enter a toll highway 40 8 from a highway entrance-44^ 40 6 (or 
405) . Then, entrance event information 402 is transmitted from 
the automated toll-collection center, the tollgate, or the like. 
Such <e«H*ffi^ conimunicaticn is typically performed under 

a radio frequency of 5.8GHz with a data transfer speed of 1Mbps. 
The entrance event information 4 02 is almost the same as™#teH^fie 
in FIG. 4 6, and thus is not described here. 0nce™^eee4^ee such 
information is received, the vehicle-mounted navigation device 
407 makes the display 5 display predetermined information such 
as payment history and cumulative amount of tolls. 
[0246] Next, presumably, the navigation device 407 reaches its 

destination, that is, a highway exit 404 (or 403), and exits the 
highway 408 therefrom. Then, exit event information 401 is 
transmitted from the automated toll-collection center, the exit, 

or the like. When ¥ : eeei¥ed- such information is received, the 

navigation device 407 makes the display 5 display such 
predetermined information as described in steps S627 and S628, 
and then makes the automated toll-collection center execute the 
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charge processing . 

[0247] As such, the navigation device of the fifth embodiment 

operates as a terminal of an automated toll-collection system so 
that better usability is offered to a user, and further, represents 
various information in a more intuitive manner so that better 
viewability is also offered to the user. 

[0248] Here, the present navigation device is described as being 

applied in an ETC automated toll-collection system on highways. 
This is not restrictive, and any type of automated toll-collection 
system will be acceptable 4^e-fe--#^ve, for example, such automated 
fare-collection system in stations as described in the fourth 
embodiment . 

[0249] Further, the map display device of the fourth embodiment 

and the navigation device of the fifth embodiment are described 
as being used for fare and toll payment for any applicable section 
on a railway and highway having faregates and™^4^p5?ree- tollgates 
placed at both ends, for example. This is not restrictive, and 
faregates and tollgates may be placed at entrance and exit of any 
chargeable area, or at any specific point where payment is charged 
by approaching and passing by the point. 
[0250] ~f Sixth Embodiment-f 

A navigation device of a sixth embodiment is similar 
in structure to that of the fifth embodiment in FIG. 47, and any 
identical component is not described again . The navigation device 
of this embodiment specifically serves as a taxi-call terminal 
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by examining information about taxis scattered therearound . 
Described next is the operation of the present navigation device 
together with the structure and operation of a taxi call system. 
[0251] FIG. 51 is a diagram showing the entire structure of 

5 a taxi call system including a navigation device operating as a 
taxi call terminal. This taxi call system is provided with a 
navigation device 1000 which is user-operable for a taxi call, 
a taxi center 2000 for dispatching a taxi on demand, and first 
to nth taxis 3001 to 300n which are locatable. Here, the number 

10 of taxis is surely not limited. 

[0252] In FIG. 51, the taxi center 2000 includes an input part 

20, a map data storage part 30, a central processing part 40, a 
display 50, a taxi information database 60, and a communications 
part 70. The structure of the taxi center 2000 can be realized 

15 by a general computer system. The structure of the taxi center 
2000 realized as such is almost the same as the map display device 
realized also by a general computer system of FIG. 2, and thus 
only — a-R-y — e^« : e^^re-e- differences therebetween — i-s- are mainly 
described here. 

20 [0253] In the taxi center 2000 of FIG. 51, the taxi information 

database 60 typically stores taxi information together with taxi 
control numbers. Here, the taxi information includes position 
information and type information, and covers every taxi under 
control . Such information may be updated in real time, at regular 

25 intervals, or responsively to an update request. 
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[0254] Also in the taxi center 2000, the central processing 

part 40 communicates, via the communications part 70, with the 
navigation device 1000, and the first to nth taxis 3001 to 300n, 
and accordingly dispatches a taxi at the user' s request . Described 
5 next below is the operation of the central processing part 40. 
[0255] FIG. 52 is a flowchart showing the operation of the 

central processing part 40 for dispatching a taxi. In step S6401 
in FIG. 52, the central processing part 40 receives, via the 
communications part 70, a user's request for taxi information 

1 0 transmitted from the user' s navigation device 1000. The operation 
of the navigation device 1000 at this time is left for later 
description. Here, such request for taxi information is 
specifically asking for information about taxis scattering around 
the area where the user currently is~r located . ^-ke^e-^-e^e- Therefore, 

15 the user's current position is transmitted together therewith. 
Also, the user's specific request for a vehicle type, fare, 
allowable distance range, and the like, may be also transmitted 
together . 

[0256] Next, in step S6402, the central processing part 40 

20 communicates with, via the communications part 70, the first to 
.nth taxis 3001 to 300ii, and asks those to each transmit~4te their 
position information, and the like. Here, the central processing 
part 40 may refer to the taxi information database 60 to selectively 
communicate with any taxi4^eate^f located close to the user, or 
25 being unchanged in position for a predetermined time period. If 
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the user' s specific request for the taxi is found m the taxi 
information, the central processing part 40 may selectively 
communicate with any taxi applicable thereto. 

[0257] Then, in step S6403, the central processing part 40 

receives, via the communications part 70, the posit ion information 
from the taxis having communicated"¥^4t therewith in step S6402. 
Since each of the taxis is typically equipped with a position 
detection device and a communications device , the detected posit ion 
information is transmitted to the taxi center 2000 via the 
communications device. Thus received position information is 
then stored in the taxi information database 60 together with the 
corresponding taxi control number. 

[0258] Note that, those steps S6402 and S6403 may be omitted 

if the taxis can be located without communications responding to 
the user's request. For example, if the position information of 
the first to nth taxis 3001 to 300n is updated at regular intervals, 
or if the taxi center 2000 can locate those taxis due to a transmitter 
provided to each thereof, those steps may be omitted. In such 
a case, the position information of the taxis is stored in the 
taxi information database 60 as appropriate. 

[0259] Then, in step S6404, the central processing part 40 

refers to the taxi information database 60, and then transmits 
the taxi information at the user' s request to the navigation device 
1000 via the communications part 70. Here, the taxi information 
includes the current position of the taxis. The taxi information 
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may also include various other types of information about a taxi' s 
company name, vehicle type, fare, estimated arrival time to the 
user, and the like. To calculate the estimated arrival time, the 
central processing part 40 refers to map data stored in the map 
data storage part 30, and then searches for a route from the taxi' s 
current position to the user' s to calculate a required time therefor . 
When the taxi center 20 0 0 does not have to search for any-^e^e 
routes, the map data storage part 3 0 may not be provided. 
[0260] In step S6405, the central processing part 40 receives, 

from the navigation device 1000 via the communications part 70, 
information about which taxi the user has selected. Such selected 
taxi information typically indicates where the user currently is 
located. Here, the operation of the navigation device 10 0 0 for 
taxi selection while referring to the taxi information transmitted 
in step S6404 will be described later. 

[0261] Next, in step S6406, the central processing part 40 

communicates with the user-selected taxi via the communications 
part 7 0 , and transmits thereto information about the user' s current 
position, and the like . At this time, the central processing part 
4 0 may guide the taxi to the user along a route searched by referring 
to the map data in the map data storage part 30. 
[0262] As is known from the above, the taxi center 2000 can 

dispatch the user-requested taxi through communications with the 
navigation device 1000 and the first to .nth taxis 3001 to 300n. 
[0263] Described next is the operation of the navigation device 



1000 . FIG. 53 is a flowchart showing the processing executed by 
the navigation device, which operates as a taxi call terminal. 
In step S8 1 in FIG . 53, a user-designated destination and map region 
are provided by the input part 2, and the user's current position 
is provided by the position detection part 9. In response, the 
route selection part 10 performs a route search, and forwards a 
result to the guiding part 11. In step S82, the guiding part 11 
then requests the map data arranging part 4 for data arrangement. 
[0264] In step S83, the map data arranging part 4 reads the 

map data from the map data storage part 3. Then, in step S84, 
the guiding part 11 typically responds to the user's instruction 
to communicate with the taxi center 2000 in FIG. 51 via the 
communications part 7, and reads taxi information for the area. 
The taxi information is forwarded to the map data arranging part 
4. The taxi information includes a taxi ID, taxi company name, 
vehicle type, a fare, for example. The process in this step 
corresponds to that in steps S6401 to S6404 in FIG. 52. Here, 
the taxi information may be automatically read at arbitrary 
intervals . 

[0265] In subroutine step S85, the map data arranging part 4 

refers to thus read communications information (taxi information) 
and information stored in the object model display information 
storage part 6, and creates taxi object models for arrangement 
on the map data. The process in subroutine step S85 is the same 
as that in subroutine step S13 in FIG. 3, and thus is not described 
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again. However, taxi object model display information will be 
described later about the details and display example thereof. 
[0266] Next, in step S86, the map data arranging part 4 

determines whether there is any interrupt event information from 
the guiding part 11 . The interrupt event information is typically 
generated by user' s input operation (e.g., sorting and selection 
by vehicle size and/or taxi company, operation for information 
request), and by a predetermined condition being set. In order 
to make a request for information, the user may put a cursor on 
any one of the taxi polygons on a screen, for example. If there 
is no interrupt event information, this is the end of procedure. 
Here, since the processing in FIG. 53 is typically executed 
repeatedly at predetermined time intervals, such determination 
in step S86 is also repeatedly made . If the information is received, 
on the other hand, the procedure goes to subroutine step S87. 
[0267] In subroutine step S87, the map data arranging part 4 

analyzes the received interrupt event information, and executes 
the corresponding object model display information stored in the 
object model display information storage part 6. If required, 
the guiding part 11 performs communications via the communications 
part 7 . 

[0268] Described here is the process in subroutine step S87 

in detail. FIG. 54 is a flowchart showing the detailed process 
in subroutine step S87. In step S872 in FIG. 54, the guiding part 
11 determines whether any specified taxi satisfies the user's 
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request. Considered here is a case where taxis are specified 
according to a user-designated condition or predetermined 
condition, for example. If any taxi satisfies the condition, the 
procedure goes to step S874«- — e^H^e^^ee Other-wise, the procedure 
goes to step S876. 

[0269] Here, such specification may be done directly by the 

user, and also by an auction among several taxis , and if s o , ^fee4^e4 

a taxi being the cheapest bidder is specified. 
[0270] In step S874, the guiding part 11 informs, via the 

communications part 7, the taxi satisfying the condition that the 
user is waiting, and asks the taxi center 2000 to forward necessary 
information via the communications part 7. To inform the taxi, 
transmitted is the selected taxi information including a taxi ID, 
position information obtained from the position detection part 
9, and the like, for specifying which taxi is the selected one. 
Surely, the guiding part 11 may communicate with both the selected 
taxi and the taxi center 2 0 0 0 to inform them that the user is waiting . 
Another possibility is that O^e? — the guiding part 11 may ask the 
selected taxi to transmit any required information, including a 
time to reach the location where the user is waiting, a. fare, any 
specific service, and if any, what service, and the like. Surely, 
such information is preferably already at the user' s hand as part 
of the taxi information. After such processing, the procedure 
goes to the process in FIG. 53. 

[0271] In step S876, the guiding part 11 informs, via the 
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communications part 7, any other taxi not satisfying the condition 
that the user is not waiting. If this operation is unnecessary, 
this processing-4e-e^kmfe^e car: be omitted. Next, in step S878, 
the guiding part 11 determines whether there is any other object 
model left for processing. If No, the procedure returns to the 
process in FIG. 53. If there is any left, the procedure returns 
to step S872. 

[0272] After step subroutine step S87, the procedure goes to 
step S88 in FIG. 53. In step S88, the map data arranging part 
4 determines whether every object model display information has 
been-^fe^fk processed. If not yet, the procedure returns to step 
S8 6 *y — a^^H^wi^re Otherwise, the procedure goes to step S89. 
[0273] In step S89, the guiding part 11 determines whether the 

guidance has been completed. If not yet, the procedure returns 
to step S 8 2 . 7 ""^4^^w-i-ae Otherwise, this is the end of procedure. 
[0274] Described next is the details of the taxi object model 

display information, and the processing carried out by the guiding 
part 11 with reference to FIGS. 55 and 56. FIG. 55 is a diagram 
showing a specific example of taxi ob j ect model display information 
430 . 

[0275] In FIG. 55, the taxi object model display information 

430 includes information about shape 431 and information about 
behavior in time and space 432 as in the case shown in FIG. 7. 
The information about shape 431 maybe 3D shape information stored 
in a f ile named "taxi . ob j for example. Or, the information about 



shape 431 may include information for defining a polygon by width, 
height, and depth, and a file named "taxi .bmp" specifying a texture 
mapped to the polygon, for example. Here, the information about 
shape 4 3 1 includes posit ion information . In FIG. 55, the position 
information is 3D coordinates at which an ob j ect model is displayed . 
A graphic on the right upper side is an example drawn according 
to the information exemplified in FIG. 55. 

[0276] The information about behavior in time and space 432 

is typically described in an object-oriented interpreter language 
not needing ^¥^T^-^e"fiee4-4ef : ---c ompilation as already described 
in FIG. 7. Once methods in the information are executed, taxi 
polygons are drawn at each currently applicable position on a map 
image. The user's click thereon or condition matching leads to 
the operation for a taxi call. If the user puts a cursor on any 
one of the taxi polygons , the corresponding taxi information (e.g., 
fare) is displayed in the vicinity thereof (in this example, on 
the right upper side) . 

[0277] By referring to FIG. 56, described next is a case where 

the information about behavior in time and space is represented 
in a format including a function name and contents thereof. FIG. 
56 exemplarily shows a function name and contents thereof for a 
taxi call, stored in the object model display information storage 
part 6. Next below, the contents of the function are described 
step by step. 

[0278] A first step is, by the guiding part 11, requesting the 



communications part 7 for obtaining taxi information specifically 
to know which taxi is vacant and in an area close to the user. 
A second step is, by the guiding part 11, requesting the map data 
arranging part 4 for executing the taxi display object model 
information based on the obtained taxi information. Here, there 
may be a case where a small-sized taxi or any specific taxi company 
is prioritized, for example. A third step is, also by the guiding 
part 11, repeating such processing as above for— a required 
number of times. A ™etH?-f ourth step is, by the map data arranging 
part 4, executing taxi object model display information and 
displaying taxi polygons in a map image. A fifth step is, by the 
guiding part 11, executing any processing requested by the map 
data arranging part 4 . Such processing may include, for example, 
ordering a taxi via the communications part 7, or displaying taxi 
information . 

[0279] After those steps are through, taxi polygons are created 

in a map space, and each appropriately arranged on a road image. 
Thereafter, if the user clicks any one of the polygons, for example, 
a taxi call is accordingly made via the communications part 7. 
Also, if the user puts a cursor on the polygon, the corresponding 
taxi information such as a fare is displayed as an object model 
eef e^-a-eei- v- separately from taxi polygons . 

[0280] FIG. 57 is a diagram showing the operation of the 

navigation device of the sixth embodiment. In FIG. 57, displayed 
on a 3D map image are taxi polygons each denoted by A or B depending 



on which taxi company together with a user's figure. Herein, a 
hand-shaped graphic with a pointing finger extended denotes a 
cursor, and thereby, the user points or clicks any specific object 
model with a mouse, for example. 

[0281] Assuming here that the user selects ■^fe^e-B' s taxi located 
in the middle of the map image. If the user brings the cursor 
close thereto, created is an object model of_a speech bubble 
displaying the corresponding taxi information therein. In this 
example, a waiting time is 5 minutes, a required time for the user' s 
destination is 20 minutes, and the fare is ¥1, 250. Here, it is 
not restrictive as to what .and how taxi information is displayed 
fn^r. Thus, the taxi information is not necessarily displayed in 
the same window, and any information will be acceptable ^et-4i-fie 
as long as the information is considered relevant to taxis, for 
example. Then, once the user clicks any one of the taxi polygons, 
the taxi call is made specifically therefor. Then, the taxi takes 
a route denoted by an arrow in the image to the user. 
[0282] Herein, if the position detection part 9, the route 

selection part 10, and the guiding part 11 are omitted from the 
navigation device of this embodiment, realized is a map display 
device functioning similarly thereto. This is because™ the 
navigation device of the present embodiment is similar in structure 
to that of the fifth embodiment in FIG. 47, except for operating 
as a taxi call terminal. Therefore, the map display device of 
the fourth embodiment is so structured as to operate as a taxi 



call terminal, realizing a map display device functioning similar 
to the present navigation device. 
[0283] -fSeventh Embodiments 

A navigation device of a seventh embodiment is similar 
in structure to that of the fifth embodiment in FIG. 47, and any 
identical component is not described again . The navigation device 
of this embodiment specifically serves as a terminal for notifying 
buses of a user' s intention of riding while examining information 
about buses scattered therearound. Described next is the 
operation of the present navigation device together with the 
structure and operation of a bus riding system. 

[0284] The entire structure of a bus riding system including 

the present navigation device is — a^H^s~& similar to the above 
described taxi call system of the sixth embodiment. FIG. 58 is 
a diagram showing the entire structure of a bus riding system 
including a navigation device 1050, which operates as a terminal 
for notifying a bus of a user's intention of riding. The system 
of FIG. 58 is-a^^T-e-fe- similar to that of FIG. 51, and any difference 
therebetween is mainly described below. In FIG. 58, a bus center 
4000 is similar in structure, but not in operation,, to the taxi 
center 2000 of FIG. 51. A bus information database 65 is similar 
in structure to the taxi information database 60 of FIG. 51, and 
a first to .nth buses 5001 to 50021 are similar to the first to nth 
taxis 3001 to 300n of FIG. 51. 

[0285] Described next is the operation of a central processing 



part 45 included in the bus center 4000. FIG. 59 is a flowchart 
showing such operation. In step S7301 in FIG. 59, the central 
processing part 45 receives, via the communications part 70, a 
user' s request for bus information transmitted from the user' s 
navigation device 1050. The operation of the navigation device 
1050 at this time is left for later description. Here, such request 
for bus information is specifically asking for information about 
buses-6€r^€~^ scattered around the area where the user currently 
is™ — fe^e^e^e^e located. Therefore, the user's current position 
and his/her destination are transmitted together therewith . Also, 
the user's specific request for a vehicle type, fare, required 
time for the destination, waiting time, and the like, may fee-also 
be transmitted together. Here, if the user's request for bus 
information is made for every bus™eth^€^±fif scattered around in 
his/her close distance range, transmitte d-^e-ee-^-^ may—fee only 
be the user' s position information. In such a case, bus selection 
is to be done on the user side. 

[0286] Next, in step S7302, the central processing part 45 

selects any bus which brings the user to his/her destination among 
■fee-f^those buses 5001 to 500,n, and asks those biases to each transmit 
their Proposition information, vacancy information, and the like. 
Here, for bus selection, the central processing part 45 refers 
to map data stored in the map data storage part 30, and compares 
bus routes with the user's route to his/her destination. When 
the bus center 4000 does not have to search for any route or make 
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such comparison, the map data storage part 30 may not be provided. 
The central processing part 45 refers to a bus timetable or schedule 
stored in the bus information database 65 to selectively 
communicate with any bus~4^t^a^4-*H* located close to the user, or 
being unchanged in position for a predetermined time period. If 
the user' s specific request for the bus is found in the bus 
information, the central processing part—4-©- 45 may selectively 
communicate with any~-fe«4r bus applicable thereto. 
[0287] Then, in step S7303, the central processing part 45 

receives, via the communications part 7 0 , the posit ion information 
and vacancy information from the buses having communicated with 
in step S7302 . Since each of the buses is typically equipped with 
a position detection device and a communications device, the 
detected posit ion information and vacancy information (for example, 
full or not) are transmitted to the bus center 4000 via the 
communications device. Thus received position information is 
then stored in the bus information database 65 together with the 
corresponding bus control number. 

[0288] Note that, those steps S7302 and S7303 may be omitted 

if the buses can be located without communications responding to 
the user's request. For example, if the position information of 
the first to .nth buses 5001 to 500^ is updated at regular intervals, 
or if the bus center 4000 can locate those buses due to a transmitter 
provided to each thereof, those steps may be omitted. In such 
a case, the position information of the buses is stored in the 
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bus information database 65 as appropriate. Alternatively, the 
bus timetable or schedule in the bus information database 65 may 
be referred to for automatically selecting any bus4^6£rfe4m located 
closer to the user' s current position without communications . If 
this is the case, it is preferable to additionally obtain vacancy 
information . 

[0289] Next, in step S7304, the central processing part 45 
refers to the bus information database 65, and then transmits the 
bus information at the user' s request to the navigation device 
1050 via the communications part 70. Here, the bus information 
includes the current position of the buses. The bus information 
may also include various other types of information about a bus's 
company name, bus route, vehicle type, fare, estimated arrival 
time and required time to the user, and the like. 
[0290] In step S7305, the central processing part 45 receives, 

from the navigation device 1050 via the communications part 70, 
information about which bus the user has selected. Such selected 
bus information typically includes the bus control number assigned 
to the user-selected bus. Here, the operation of the navigation 
device 10 5 0 for bus selection while referring to the bus information 
transmitted in step S7304 will be described later. 
[0291] Next, in step S7306, the central processing part 45 

communicates with the user-selected bus via the communications 
part 7 0 , and transmits thereto information about the user' s current 
position, and the like. Instead, transmitted may be a control 



number assigned to a bus stop located close to the user . The central 
processing part 45 then notifies other buses that the user is not 
waiting. To be specific, the central processing part 45 refers 
to the map data stored in the map data storage part 30, searches 
for a bus stop at wh i ch--e^^e-ire±^ the user is currently standing, 
and to any bus passing by the bus stop, notifies that the user 
is not waiting. In this manner, even if the bus finds the user 
standing at the bus stop, the bus can pass by without stopping 
as that bus is informed in advance that he/she is not waiting for 
it . 

[0292] Described next is the operation of the navigation device 

1050. FIG. 60 is a flowchart showing the processing executed by 
the navigation device, which operates as a terminal for examining 
bus information. In step S910 in FIG. 60, a user-designated 
destination and map region are provided by the input part 2, and 
the user' s current position is provided by the position detection 
part 9. In response, the route selection part 10 performs a route 
search, and forwards a result to the guiding part 11. In step 
S920, the guiding part 11 then requests the map data arranging 
part 4 for data arrangement. 

[0293] In step S930, the map data arranging part 4 reads the 

map data from the map data storage part 3. Then, in step S940, 
the guiding part 11 reads,, via the communications part 7, bus 
information for the area. The bus information is then forwarded 
to the map data arranging part 4 . The^e-x4- bus information includes 
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a bus ID, bus company name, bus route, fare, for example. The 
process in this step corresponds to that in steps S7301 to S7304 
in FIG. 59. Here, the bus information may be automatically read 
at arbitrary intervals. 

[0294] In subroutine step S950, the map data arranging part 

4 refers to thus read communications information (bus information) 
and information stored in the object model display information 
storage part 6, and creates bus object models for arrangement on 
the map data. The process in subroutine step S950 is the same 
as that in subroutine step S13 in FIG. 3, and thus is not described 
again. However, bus object model display information will be 
described later about the details and display example thereof. 
[0295] Next, in step S960, the map data arranging part 4 

determines whether there is any interrupt event information from 
the guiding part 11 . The interrupt event information is typically 
generated by user's input operation (e.g., operation for 
information request) , and by a predetermined condition being set . 
If there is no interrupt event information, this is the end of 
the procedure. Here, since the processing in FIG. 60 is typically 
executed repeatedly at predetermined time intervals, such 
determination in step S960 is also repeatedly made. If the 
information is received, on the other hand, the procedure goes 
to subroutine step S970. 

[0296] In subroutine step S970, the map data arranging part 

4 analyzes the received interrupt event information, and executes 
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the corresponding object model display information stored in the 
object model display information storage part 6. If required, 
the guiding part 11 performs communications via the communications 
part 7 . 

5 [0297] Described here is the process in subroutine step S970 

in detail. FIG. 61 is a flowchart showing the detailed process 
in subroutine step S970. In step S971 in FIG. 61, the guiding 
part 11 determines whether any specified bus is suitable for a 
guiding route. That is, the guiding part 11 determines whether 

10 the specified bus appropriately brings the user to his/her 
destination . If determined Yes, the procedure goes to step S972 .™ 
Otherwise, the procedure goes to step S976. Here, the 
bus route may be the one included in the object model display 
information, or a result found by the guiding part 11. In the 

15 case that the user' s destination is forwarded to the bus center 
4000 for comparison with the bus routes therein, the process in 
this step is omitted, since the thus specified bus is always 
appropriate . 

[0298] In step S972, the guidingpart 11 then determines whether 

20 any specified bus satisfies the user's specific request. 
Considered here is a case where buses are specified according to 
a user-designated condition or predetermined condition, for 
example. If any bus satisfies the condition, the procedure goes 
to step S97 4 .7 — e^^e^^e^r Otherwise, the procedure goes to step 
25 S976. Here, such specification may be done directly by the user, 
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[0299] In step S974, the guiding part 11 informs, via the 

communications part 7, the bus satisfying the condition that the 
user is waiting, and asks the bus information center 4000 to forward 
necessary information via the communications part 7. To inform 
the bus, transmitted is the selected bus information including 
a bus ID, position information obtained from the position detection 
part 9, and the like, for specifying which bus is the selected 
one. Surely, the guiding part 11 may communicate with both the 
selected bus and the bus center 4 0 00 to inform them that the user 
is waiting. Another possibility is that -G^v the guiding part 11 
may ask the selected bus to transmit any required information, 
including a time to reach the location where the user is waiting, 
fare, vacancy information, and the like. Surely, such information 
is preferably already at the user' s hand as part of the bus 
information. After such processing, the procedure goes to the 
main routine in FIG. 60. 

[0300] In step S976, the guiding part 11 informs, via the 

communications part 7, any other bus not satisfying the condition 
that the user is not waiting for them. If this operation is 
unnecessary, this processing can be omitted i-e-e^^^e-ife-^e . Next, 
in step S978, the guiding part 11 determines whether there is any 
other object model left for processing. If No, the procedure 
returns to the process in FIG. 60. If there is any object model 
left, the procedure returns to step S972. 

[0301] After step subroutine step S970, the procedure goes to 
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step S980 in FIG. 60. In step S980, the map data arranging part 
4 determines whether every object model display information has 
been processed If not yet, the procedure returns to step 

S960 Otherwise, the procedure goes to step S990. 

[0302] In step S990, the guiding part 11 determines whether 

the guidance has been completed. If not yet, the procedure returns 
to step S 9 2 0 * T-^^-h-e^^-ee^ Otherwise, this is the end of procedure. 
[0303] Described next is the details of the bus object model 

display information, and the processing carried out by the guiding 
part 11 with reference to FIGS. 62 and 63. FIG. 62 is a diagram 
showing a specific example of bus object model display information 
480 . 

[0304] In FIG. 62, the bus object model display information 

480 includes information about shape 481 and information about 
behavior in time and space 482,, as in the case shown in FIG. 55. 
The information about shape 481 maybe 3D shape information stored 
in a file named "bus . ob j " , for example. Another possibility it 
that; Or-- the information about shape 481 may include information 
for defining a polygon by width, height, and depth, and a file 
named "bus.bmp" specifying a texture mapped to the polygon, for 
example. As in FIG. 55, the information about shape 481 includes 
position information . 

[0305] The information about behavior in time and space 482 

is similar to that of FIG. 55. Once methods in the information 
are executed, bus polygons are drawn at each currently applicable 
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position on a map image, and™™s^f& show corresponding bus 
information telling its route number, waiting time, and the like. 
If any bus is found full, an object model ^Full" is displayed on 
the applicable bus polygon. The user's click on a specific bus 
polygon or condition matching leads to the operation for notifying 
the bus of the user' s desire to ride the bus -^4^^—-^. With the 
user-^e-ee riding on the bus, the guiding part 11 is asked, via 
the communications part 7, to pay the bus fare. Such fare payment 
system includes ETC, for example. 

[0306] By referring to FIG. 63, described next is a case where 
the information about behavior in time and space is represented 
in a format including a function name and contents thereof. FIG. 
63 exemplarily shows a function name and contents thereof for a 
bus call™ stored in the object model display information storage 
part 6. Next below, the contents of the function are described 
step by step. 

[0307] A first step is, by the guiding part 11, requesting the 

communications part 7--#^^--^fe^a-i^vh-fre to obtain bus information in 
a close distance range. A second step is, by the guiding part 
11, requesting the map data arranging part 4 for executing the 
bus display object model information based on the obtained bus 
information. Here, without the user ' s instruction f if necessary, 
the guiding part 11 notifies,, via the communications part 7 f 
applicable buses that the user does not intend ride thereon. This 
is because, by doing so, the unselected bus4^s™^e does not need 

105 



to stop by the bus stop where the user is standing alone. A third 
step is, also by the guiding part 11, repeating such processing 
as above forn^e a required number of times. A-#s-bH^ fourth step 
is, by the map data arranging part 4, executing bus object model 
display information and displaying bus polygons in a map image. 
A fifth step is, by the guiding part 11, executing any processing 
requested by the map data arranging part 4. Such processing may 
include, for example, paying a bus fare,, via the communications 
part 7, if the user rides on the bus. 

[0308] After those steps are through, bus polygons are created 
in a map space, and each is appropriately arranged on a road image. 
Thereafter, if the user determines to take a bus and then clicks 
an applicable bus polygon, for example, a bus call is accordingly 
made via the communications part 7 . 

[0309] FIG. 64 is a diagram showing the operation of the 

navigation device of the seventh embodiment . InFIG. 64, displayed 
on a 3D map image are bus polygons each numbered 3 or 5 together 
with a user ' s figure . Herein, a hand- shaped graphic with a pointing 
finger extended denotes a cursor, and thereby, the user points 
or clicks any specific object model with a mouse, for example. 
If the user selects the bus No. 3 located in the middle of the 
map image, the bus is notified that the user i s-^-i-^i-R-e intends 
to ride the bus. Then, another object model indicating the number 
of the bus and the estimated arrival time is displayed on the left 
side of the user's object model. Here, the object model may be 

106 



displayed on the map image at a position corresponding to a bus 
stop closest to the user. Then, the bus takes a route denoted 
by an arrow in the image to the user. 

[0310] Herein, if the position detection part 9, the route 

selection part 10, and the guiding part 11 are omitted from the 
navigation device of this embodiment, realized is a map display 
device functioning similarly thereto. This is because-- the 
navigation device of the present embodiment is similar in structure 
to that of the fifth embodiment in FIG. 47, except for operating 
as a bus call terminal. Therefore, the map display device of the 
fourth embodiment is so structured as to operate as a bus call 
terminal, realizing a map display device functioning similar to 
the present navigation device. 

[0311] Such navigation devices of the sixth and seventh 

embodiments can be implemented in one device wherein two different 
functions are simultaneously achieved by including a traffic 
information center, for example, working as both the taxi center 
2000 and the bus center 4000 . If this is the case, such navigation 
device receives taxi information and bus information from the 
traffic information center. Then, selection about which taxi or 
bus to take is made, and the corresponding taxi or bus control 
number, for example, is transmitted to the traffic information 
center. In such a. manner, the user can intuitively understand 
information about taxis and buses on the way to his/her destination, 
and accordingly the user can be offered better usability. 
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[0312] Further, the navigation devices of the sixth and seventh 

embodiments can be so structured as to display other users' 
information only with a minor change in operation of the guiding 
part 11 or the map data arranging part 4. To be specific, the 
present navigation device exchanges, via the communications part 
l r position information with the traffic information center or 
with any other specific user' s navigation device . Then, a specific 
object model indicating the other user's navigation device is 
arranged on the map image at the appropriate position. 
[0313] For example, by setting that the user of the present 

navigation device can receive position information of his/her 
friend' s navigation device, the friend' s position can be displayed 
on the map image. FIG. 65 shows an exemplary map image having 
friends' positions each displayed on the map image. As shown in 
FIG. 65, if other user' s names, their vehicle types, and the like, 
are specifically registered in advance, the user can understand 
information more intuitively. 

[0314] While the invention has been described in detail, the 

foregoing description is in all aspects illustrative and not 
restrictive. It is understood that numerous other modifications 
and variations can be devised without departing from the scope 
of the invention. 
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ABSTRACT OF THE DISCLOSURE 



In a map display device , a communications part™? receives 
various information from an external system, and a map data 
arranging part— 4 arranges in a map space object models each 
indicating those various information. Such data arrangement is 
done based on map data stored in a map data storage part — ?, 
information from the communications part—? and an input part™?, 
and object model display information stored in an object model 
display information storage part~™&. A display—? then displays 
a resultant map image. In such manner, various time-varying 
information are appropriately arranged for display on the map image 
so as to make a user intuitively understand what those information 
mean . 
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